Skip to content
#587 / WINDOWS

WSL2 prend trop de place, comment réduire le fichier ext4.vhdx

Windows m'a pris 70 Go d'espace disque sans prévenir. Aucun fichier visible dans l'Explorateur, rien dans le nettoyage de disque, et pourtant mon disque C affichait complet. Si vous développez sous WSL2 ou si

7 min Adrien
WSL2 prend trop de place, comment réduire le fichier ext4.vhdx

Windows m’a pris 70 Go d’espace disque sans prévenir. Aucun fichier visible dans l’Explorateur, rien dans le nettoyage de disque, et pourtant mon disque C affichait complet. Si vous développez sous WSL2 ou si vous y stockez de gros volumes de données, vous êtes probablement dans la même situation sans le savoir.

Le coupable est un fichier unique, ext4.vhdx, le disque virtuel qui contient toute votre distribution Linux. J’ai mesuré le phénomène sur mon propre poste de travail avant de le corriger. Ubuntu utilisait 38 Go de données réelles, le fichier occupait 110 Go côté Windows. Je vous montre comment vérifier votre cas, puis comment récupérer l’espace en cinq minutes.

Pourquoi votre disque C se remplit alors que vous n’avez rien installé

WSL2 stocke l’intégralité de votre environnement Linux dans un seul disque virtuel au format VHDX, provisionné par défaut jusqu’à 1 To selon la documentation Microsoft sur l’espace disque WSL. Ce fichier fonctionne en expansion dynamique. Il grossit à chaque écriture, une mise à jour apt, un npm install, un téléchargement, et Windows ne réduit jamais sa taille de lui-même.

Le piège tient à la séparation entre les deux mondes. Quand vous supprimez des fichiers dans Ubuntu, l’espace redevient disponible à l’intérieur de la machine virtuelle. Linux le voit libre et peut le réutiliser. Windows, lui, continue de voir un fichier ext4.vhdx à sa taille maximale historique. L’espace existe des deux côtés à la fois, mais vous ne pouvez l’utiliser que d’un seul.

C’est pour cette raison que le nettoyage de disque de Windows, WinDirStat ou TreeSize ne vous montrent rien d’anormal. Ils voient un gros fichier système légitime, pas l’écart entre son contenu réel et sa taille sur le disque.

Le problème touche tout usage de WSL2, pas seulement Docker

N’importe quelle écriture volumineuse déclenche le mécanisme. Copiez 150 Go de photos dans votre home Linux pour un tri, supprimez-les une fois terminé, et le fichier vhdx conserve ses 150 Go sur le disque C. Un jeu de données d’entraînement, un export vidéo, une sauvegarde décompressée produisent exactement le même effet. Le contenu ne compte pas, seul le volume écrit compte.

Espace réel contre espace occupé par WSL2 sur le disque C Ubuntu contient 38 Go de données réelles mais le fichier ext4.vhdx occupe 110 Go sur Windows, soit plus de 70 Go d’espace fantôme. Espace réel contre espace occupé sur le disque C Distribution Ubuntu WSL2, mesure avant compactage Données réelles dans Ubuntu 38 Go Taille du fichier ext4.vhdx côté Windows 110 Go Plus de 70 Go d’espace fantôme bloqués côté Windows Mesure Assistouest sur poste de travail, juillet 2026

Docker reste le cas le plus fréquent chez les développeurs, parce que les images, les volumes et le cache de build s’accumulent vite. Un docker system prune libère bien des dizaines de gigaoctets, mais uniquement à l’intérieur de la machine virtuelle. L’espace nettoyé reste prisonnier du disque virtuel tant que celui-ci n’est pas compacté. Notez au passage que Docker Desktop utilise son propre vhdx, docker-desktop-data, distinct de celui de votre distribution Ubuntu. Les deux peuvent gonfler.

Vérifier combien d’espace vous pouvez récupérer

La vérification prend deux minutes et repose sur la comparaison de deux chiffres. Le premier est l’espace réellement utilisé par votre distribution, le second la taille du fichier vhdx vue par Windows. La différence entre les deux représente l’espace que vous allez récupérer.

Premier chiffre. Ouvrez votre terminal WSL et mesurez l’usage réel de la distribution.

df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdd       1007G   38G  918G   4% /

La colonne Used donne votre premier chiffre, ici 38 Go. Ne vous fiez pas à la colonne Size, qui affiche environ 1 To. C’est la taille maximale provisionnée par WSL, pas la capacité de votre disque physique.

L’emplacement du fichier vhdx varie selon la façon dont WSL a été installé, alors le plus fiable est de le faire chercher par Windows. Ouvrez PowerShell et collez cette commande. Elle parcourt votre profil utilisateur et affiche chaque disque virtuel de distribution avec son chemin complet et sa taille en Go.

Get-ChildItem $env:LOCALAPPDATA -Recurse -Filter ext4.vhdx -ErrorAction SilentlyContinue | Select-Object FullName, @{n="Go";e={[math]::Round($_.Length/1GB,1)}}
FullName                                                    Go
--------                                                    --
C:\Users\adrien\AppData\Local\wsl\{c16045d3-...}\ext4.vhdx 110

Vous obtenez une ligne par distribution installée, plus une pour Docker Desktop le cas échéant. Copiez précieusement ce chemin, c’est lui que vous reporterez dans diskpart à l’étape suivante. La commande cible volontairement les fichiers ext4.vhdx, les seuls qui comptent. Les swap.vhdx que vous pourriez croiser ailleurs sont de simples fichiers d’échange temporaires, ils se vident seuls à l’arrêt de WSL.

Sur mon poste, la comparaison donnait 38 Go réellement utilisés pour un fichier de 110 Go. Plus de 70 Go à récupérer, sans rien supprimer. Précision utile, un disque qui sature n’est pas un disque qui meurt. Les symptômes d’un disque défaillant sont d’une toute autre nature, lenteurs, bruits, secteurs illisibles.

La procédure diskpart pour compacter le disque en 5 minutes

Le compactage force Windows à réécrire le fichier vhdx à sa taille réelle. L’opération est sans danger pour vos données, le disque est attaché en lecture seule pendant toute la manipulation. Commencez par arrêter complètement WSL depuis un terminal.

wsl --shutdown

Fermez aussi Docker Desktop s’il tourne, icône de zone de notification comprise. C’est le piège classique, un Docker resté ouvert relance WSL en arrière-plan et diskpart refusera d’attacher le disque. Ouvrez ensuite une invite de commandes en mode administrateur et lancez l’utilitaire de gestion des disques.

diskpart

Exécutez enfin ces 4 commandes en adaptant le chemin vers votre propre fichier, celui repéré à l’étape précédente.

select vdisk file="C:\Users\<vous>\AppData\Local\wsl\<id>\ext4.vhdx"
attach vdisk readonly
compact vdisk
detach vdisk

Le compactage affiche sa progression en pourcentage puis rend la main. Sur mon poste, le fichier est passé de 110 Go à un peu moins de 40 Go et l’Explorateur a reflété le changement immédiatement. Relancez ensuite WSL normalement, vos données n’ont pas bougé.

Source préférée Google Ne subissez pas l’algorithme

Ajoutez Assistouest à vos sources préférées sur Google pour retrouver nos guides plus vite quand vous cherchez une solution informatique.

Mettre en favori

Les alternatives Optimize-VHD et le mode sparse valent-elles le détour

Deux autres méthodes existent et vous les croiserez dans les discussions anglophones. La première, la cmdlet PowerShell Optimize-VHD, donne un résultat équivalent à diskpart mais réclame Hyper-V, donc une édition Windows Pro ou Enterprise, comme le détaille le guide de Stephen Rees-Carter sur la réduction des disques WSL2. Sous Windows Famille, elle n’existe pas.

La seconde est le mode sparse introduit avec WSL 2.0 en septembre 2023, activable par la commande wsl --manage <distro> --set-sparse true. Sur le papier, il restitue l’espace automatiquement à chaque suppression. Dans la pratique, des utilisateurs signalent sur Microsoft Q&A des disques sparse qui ne rétrécissent plus et deviennent impossibles à compacter manuellement. J’ai préféré ne pas confier mes 70 Go à une fonctionnalité aussi capricieuse et je reste sur diskpart, disponible partout et prévisible.

MéthodePrérequisFiabilité
diskpart, compact vdiskAucun, présent sur toutes les éditions de WindowsExcellente, la méthode de référence
Optimize-VHDWindows Pro ou Enterprise avec Hyper-VBonne, résultat équivalent à diskpart
Mode sparse de WSLWSL 2.0 minimumAléatoire, bugs d’espace jamais restitué signalés

Votre plan d’action en résumé

Le fichier ext4.vhdx de WSL2 ne rétrécit jamais seul, et l’écart entre son contenu et sa taille sur le disque peut atteindre des dizaines de gigaoctets. 4 commandes diskpart règlent le problème en 5 minutes, sans risque pour vos données grâce au montage en lecture seule. Pensez à répéter l’opération périodiquement si vous manipulez de gros volumes.

Et si votre disque sature sans que WSL soit en cause ou si vous préférez confier la manipulation à quelqu’un dont c’est le métier, notre service de dépannage informatique à distance diagnostique ce type de saturation en une session.