WSL-Speicher freigeben: Warum Löschen die VHDX nicht verkleinert
Löschst Du Dateien in WSL 2, wird zunächst Platz im Linux-Dateisystem frei. Die dynamische Datei ext4.vhdx auf Windows schrumpft dadurch meist nicht sofort. Um Platz auf C: zurückzubekommen, prüfst Du zuerst beide Seiten, sicherst Deine Daten und bereinigst sie anschließend. Danach kannst Du die VHDX bei beendetem WSL kompaktieren; wie viel das bringt, zeigt die Messung nach dem Eingriff.
Warum C: voll bleibt, obwohl Linux freien Platz meldet
WSL 2 legt das Linux-Dateisystem in einer virtuellen Festplatte ab, die Windows als VHDX-Datei sieht. Sie ist dünn provisioniert: Ihre virtuelle Kapazität steht bereit, doch die Datei wächst erst mit dem Bedarf. Eine gewöhnliche dynamische VHD behält ihren Platz, wenn Du darin Dateien löschst; Sparse-VHDs können sich anders verhalten.
Laut Microsofts Beschreibung der WSL-Datenträger beträgt das Standardlimit heute 1 TB; der konkrete Standardwert entspricht 1 TiB, also 1024 GiB. Das ist keine Zusage, dass auf Deiner SSD so viel frei ist: Eine Linux-Distribution kann diese Kapazität auch auf einer kleineren Windows-Platte anzeigen.
Genau das führte uns im Juni 2026 auf unserem Rechner in die Irre. C: hatte damals rund 475 GB Kapazität und nur wenige GB frei, während Ubuntu in WSL etwa 720 GB freien Platz meldete. Das passte zur virtuellen Größe, half Windows aber kein Stück.
In der Distribution lag ein Server-Backup mit rund 126 GB und 2,9 Millionen Dateien, dazu ein fertiges Archiv mit 27 GB. Beim weiteren Packen innerhalb von WSL wuchs die VHDX weiter, bis der Vorgang bei nur noch etwa 1 GB freiem Platz auf C: abbrach. Ausgerechnet das Verpacken zum Aufräumen verschärfte also den Engpass.
Später hatten wir rund 156 GB Daten in einer etwa 248 GB großen VHDX. Die Differenz gab den Anlass, eine Kompaktierung zu planen, belegte aber noch keinen gewonnenen Speicherplatz. Alle diese Zahlen stammen aus unseren Notizen vom Juni; inzwischen steckt eine größere Platte im Rechner.

Erst messen: Linux, VHDX und Windows getrennt
Beginne im Linux-Terminal mit diesen beiden lesenden Befehlen, die wir am 9. September 2026 auf unserem Rechner ausgeführt haben:
df -h /
df -h /mnt/cDie erste Zeile fragt das Linux-Dateisystem ab, die zweite das eingebundene Laufwerk C:. Bei dieser Ausgabe steht G für GiB und T für TiB, also für Einheiten auf Basis von 1024. Ein Hersteller-GB rechnet dagegen mit einer Milliarde Bytes, weshalb die Werte für Deinen Vergleich in derselben Einheit vorliegen müssen.
| Messung am 09.09.2026, 11:19 Uhr | Ergebnis | Was Du daraus abliest |
|---|---|---|
| Linux-Dateisystem | 1007 GiB gesamt, 685 GiB belegt, 271 GiB verfügbar | Platz innerhalb der Distribution |
| Windows-Laufwerk C: | 1,9 TiB gesamt, 1,5 TiB belegt, 332 GiB frei | Reserve auf dem Laufwerk, das die VHDX trägt |
| VHDX-Dateilänge | 771043098624 Bytes, etwa 771,0 GB oder 718,1 GiB | Größe der Datei, noch keine Messung ihrer physischen NTFS-Belegung |
Die mit stat ermittelte Dateilänge ist nicht die NTFS-Belegung, deshalb lässt sich aus der Differenz zwischen 718,1 GiB und 685 GiB keine Ersparnis ableiten.
Die Versionsabfrage mit wsl.exe --version bestätigte WSL 2.6.3.0 auf Windows 11 mit Ubuntu 24.04; als Linux-Kernel lief 6.6.87.2-microsoft-standard-WSL2.
Die richtige ext4.vhdx finden
Bei Store-Installationen findest Du häufig einen Pfad nach diesem Muster:
%LOCALAPPDATA%\Packages\<Paketname>\LocalState\ext4.vhdxAuf unserem Rechner liegt die Datei unter %LOCALAPPDATA%\wsl\<Distribution-ID>\ext4.vhdx, weshalb Du keinen festen Pfad aus einer Anleitung übernehmen solltest. Microsoft beschreibt diese Befehlsfolge mit einem lesenden PowerShell-Ausdruck zur Abfrage des registrierten Basispfads, hier nicht selbst ausgeführt:
wsl --list --verbose
(Get-ChildItem -Path HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss | Where-Object { $_.GetValue("DistributionName") -eq '<Distribution>' }).GetValue("BasePath") + "\ext4.vhdx"Setze bei <Distribution> den Namen aus der Liste ein und prüfe, ob die Versionsspalte für diesen Ablauf 2 anzeigt. Notiere den ermittelten Dateipfad und halte in den Dateieigenschaften unter Windows Größe und Größe auf Datenträger getrennt fest.
Platz in Linux schaffen: erst die großen Ordner prüfen
Wir haben auch zwei typische Verzeichnisse im eigenen Home-Verzeichnis gemessen:
du -xsh "$HOME/.cache" "$HOME/.npm"Das Ergebnis am 9. September 2026: 14 GiB unter .cache und 9,2 GiB unter .npm. Der Schalter -s liefert je Ordner eine Summe, während -x die Suche auf das jeweilige Dateisystem begrenzt und darunter eingehängte andere Dateisysteme überspringt.
Diese Größen sind keine Löschfreigabe: Prüfe, zu welchem Programm die Inhalte gehören und ob Du sie noch brauchst. Für eine breitere Suche einschließlich versteckter Verzeichnisse hilft Dir unsere Anleitung, wie Du unter Linux die größten Ordner findest.
- Backups und Archive: Prüfe zuerst doppelte Kopien, alte Exporte und bereits übertragene Archive.
- Paket- und Build-Caches: Nutze nach der Prüfung die Bereinigung des jeweiligen Werkzeugs.
- Alte Entwicklungsumgebungen: Kläre bei virtuellen Umgebungen und Browserpaketen, welches Projekt sie noch braucht.
- Docker-Daten: Trenne entbehrliche Images und Build-Caches von Volumes mit wichtigen Daten und prüfe, welche VHDX diese Daten enthält.
- Snapshots und Sicherungskopien: Prüfe vor dem Entfernen, welche Version Dein letzter brauchbarer Rückweg ist.
Bei uns brachte das Aufräumen von Caches und alten Umgebungen im Juni rund 13,7 GB innerhalb der VHDX, während C: dadurch keinen Platz gewann. Der nächste Schritt muss also zum Engpass passen: Braucht Linux freie Blöcke, hilft die Bereinigung direkt; braucht Windows freien Platz, folgt die Prüfung der VHDX.
Lagere große Archive auf ein anderes Laufwerk mit genug freiem Platz aus, denn ein anderer Ordner unter C: nutzt weiter dasselbe knappe Laufwerk. Sichere Daten dort, wo Du die Kopie prüfen kannst, und entferne die entbehrliche Quelle erst nach erfolgreicher Prüfung. Ein Archiv innerhalb derselben WSL-Distribution ist dafür bei vollem C: ein schlechter Zwischenstopp.
VHDX verkleinern: der Ablauf mit Windows-Bordmitteln
Den folgenden Ablauf nach Microsoft-Dokumentation haben wir am 09.09.2026 nicht selbst ausgeführt, deshalb gibt es keinen Vorher-Nachher-Wert. Die WSL-Referenz beschreibt Shutdown und Datenträgerauswahl, die separate Referenz zu compact vdisk die Kompaktierung unter Windows 10 und Windows 11.
Vor dem Eingriff: Sichere wichtige Daten außerhalb der Distribution und prüfe die Sicherung. Speichere offene Arbeit und beende laufende Aufgaben sauber, denn ein WSL-Shutdown beendet alle laufenden Distributionen. Schließe auch Docker Desktop und Programme, die WSL erneut starten könnten.
Öffne ein Windows-Terminal als Administrator; für die Kompaktierung muss die dynamische VHD abgetrennt oder nur lesend eingebunden sein. Für die abgetrennte Variante beendest Du zuerst WSL und startest danach DiskPart:
wsl --shutdown
diskpartGib im DiskPart-Prompt die folgenden Zeilen einzeln ein und ersetze den Platzhalter durch den vollständigen, zuvor ermittelten Pfad zur richtigen VHDX. Die Auswahl gilt für genau diese Datei:
select vdisk file="<Vollständiger-Pfad-zur-ext4.vhdx>"
compact vdisk
exitKontrolliere nach der ersten Zeile, ob DiskPart die gewünschte Datei erfolgreich ausgewählt hat, und gehe bei einer Fehlermeldung nicht zur nächsten Zeile weiter. Meldet Windows eine belegte Datei, prüfe erneut, ob eine Anwendung WSL gestartet hat. Warte die Kompaktierung ab, bevor Du die Distribution wieder öffnest.
Notiere anschließend die VHDX-Größe und den freien Platz auf C:, starte Linux und wiederhole die beiden df-Messungen. Öffne wichtige Dateien und prüfe Deine Anwendungen, damit auch deren Funktion Teil der Kontrolle ist. Die virtuelle Linux-Kapazität soll durch eine Kompaktierung nicht kleiner werden; gesucht ist mehr freier Platz auf dem Windows-Laufwerk.
Microsoft weist beim verwandten PowerShell-Befehl Optimize-VHD ausdrücklich darauf hin, dass eine erfolgreiche Kompaktierung ohne kleinere Datei enden kann. Rechne deshalb nicht mit einer festen Zahl an gewonnenen Gigabytes, nur weil Linux freie Blöcke meldet.
Wann Optimize-VHD oder Export und Import passen
Optimize-VHD gehört zum Hyper-V-Modul, das zusätzlich zu PowerShell vorhanden sein muss. Bei Windows 11 nennt Microsoft Pro, Enterprise und Education als Hyper-V-Editionen; für Windows Home ist DiskPart der hier beschriebene Weg. Ein zusätzliches Optimize-VHD-Rezept brauchst Du für denselben Versuch nicht.
Willst Du die ganze Distribution auf ein anderes Laufwerk bringen, sind Export und Import eine Alternative. Laut Microsofts WSL-Befehlsreferenz kannst Du ein TAR-Archiv exportieren und unter einem neuen Namen importieren:
wsl --export <Distribution> "E:\WSL-Backup\linux.tar"
wsl --import <Neue-Distribution> "E:\WSL-Neu" "E:\WSL-Backup\linux.tar" --version 2Das Laufwerk E: ist ein Beispiel für ein anderes Laufwerk mit ausreichend Platz für den Export und die neue Distribution. Lege den Sicherungsordner vorher an und beende schreibende Anwendungen vor der Sicherung sauber. Prüfe im neuen System Dateien, Benutzerkonto und Dienste, während die alte Distribution noch vorhanden ist. Export und Import sind ein eigener Umzug, kein schneller Aufräumknopf.

Sparse, Größenlimit und RAM: drei verschiedene Dinge
Sparse-Dateien können ungenutzte Bereiche freigeben, ohne ihre logische Länge entsprechend zu kürzen; Microsoft stellte dafür eine automatische Platzrückgabe für WSL vor. Der dort dokumentierte Schalter für bestehende Distributionen lautet wsl --manage <Distribution> --set-sparse true; mit false wird Sparse deaktiviert.
Die Einstellung sparseVhd=true gehört laut aktueller WSL-Konfigurationsreferenz unter [experimental], gilt für neu erzeugte VHDs und steht standardmäßig auf false. Der offizielle Quelltext von WSL 2.6.3 enthält zudem eine Warnung vor möglicher Datenbeschädigung durch Sparse-VHDs. Der Warntext nennt dieses Risiko als Grund für die deaktivierte Sparse-Unterstützung in dieser Version. Für eine wichtige Arbeitsdistribution empfehlen wir den Schalter deshalb nicht als pauschalen Spartipp. Die Aussicht auf automatische Platzrückgabe reicht hier nicht aus, um das vom Hersteller benannte Risiko in Kauf zu nehmen.
wsl --manage <Distribution> --resize <Größe> beschreibt Microsoft dagegen zum Vergrößern der virtuellen Kapazität, ab WSL 2.5. Auch defaultVhdSize betrifft das Größenlimit der virtuellen Platte; beides ist kein Ersatz für die Kompaktierung einer bereits großen Datei.
autoMemoryReclaim gibt zwischengespeicherten Arbeitsspeicher zurück, verkleinert aber nicht Deine Linux-Festplatte. Daneben kann WSL eine eigene Swap-Datei nutzen, standardmäßig %Temp%\swap.vhdx, die bei der Suche nach großen Windows-Dateien getrennt von der ext4.vhdx auf die Liste gehört.
Wenn die Zahlen weiter nicht zusammenpassen
Linux kann Speicher für die Verwaltung und für reservierte Blöcke benötigen, wie unser älterer Beitrag über reservierten Platz bei ext4 erklärt. Die dort beschriebene Änderung auf einer Datenplatte ist keine pauschale Empfehlung für Dein WSL-Systemlaufwerk.
Auch Anwendungen können große Hilfsdateien hinterlassen, wie unser historischer GIMP-Fall mit einer großen Swap-Datei an einer älteren Programmversion zeigt. Auf Windows kommen eigene Dateien wie die Ruhezustandsdatei hinzu, deren Belegung durch das Verkleinern der Linux-VHDX nicht beseitigt wird.
Deine nächste Handlung richtet sich nach der vollen Ebene: Ist Linux voll, suche dort die großen Ordner. Ist C: voll, prüfe die VHDX und die übrigen Windows-Dateien. Sind wichtige Daten gesichert und in Linux viele Blöcke frei, plane einen einzelnen Kompaktierungslauf und vergleiche danach dieselben Messwerte erneut.

Alle Kommentare als Feed abonnieren




















