Warum WSL2 und Docker die Festplatte füllen: ext4.vhdx verkleinern
Der virtuelle Datenträger wächst und schrumpft nie von allein
Kurze Antwort: WSL2 speichert das gesamte Linux-Dateisystem in einer virtuellen Festplatte namens `ext4.vhdx`. Diese Datei wächst bei Bedarf, wird aber NICHT kleiner, wenn Sie darin Dateien löschen. Um Platz zurückzugewinnen, räumen Sie zuerst innerhalb der Distribution auf, führen dann `wsl --shutdown` aus und komprimieren die Datei mit `diskpart`.
Das ist die häufigste Ursache für "meine Systempartition ist voll und ich finde nicht, was sie belegt" auf Entwicklerrechnern. Analysewerkzeuge zeigen eine einzelne 80-GB-Datei, und Sie trauen sich nicht, sie anzufassen — zu Recht, denn ein Löschen nimmt die gesamte Linux-Umgebung mit. Dieser Leitfaden erklärt, was die Datei ist, wie Sie sie gefahrlos verkleinern und wie Sie das Aufblähen künftig verhindern.
Das Wichtigste in Kürze
- WSL2 legt das komplette Linux-Dateisystem in einer einzigen `ext4.vhdx` ab, die wächst, aber nie automatisch schrumpft.
- Die Datei liegt meist unter `%LOCALAPPDATA%\Packages\<Distribution>\LocalState\ext4.vhdx`; Docker Desktop nutzt eine eigene `docker_data.vhdx`.
- Die Reihenfolge zählt: erst Daten INNERHALB der Distribution löschen, dann den virtuellen Datenträger komprimieren.
- Bei Docker gibt `docker system prune -a --volumes` oft allein schon zig Gigabyte frei.
- `wsl --shutdown` ist vor dem Komprimieren zwingend; eine benutzte Datei lässt sich nicht verkleinern.
- Ab WSL 2.0 sorgt `sparseVhd=true` in der `.wslconfig` dafür, dass der Datenträger mit der Zeit von selbst schrumpft.
Warum sie wächst und nie schrumpft
WSL2 ist eine echte virtuelle Maschine und legt das gesamte Linux-Dateisystem auf der Windows-Seite in einer einzigen Datei ab: `ext4.vhdx`. Es handelt sich um einen dynamisch wachsenden virtuellen Datenträger. Bei 5 GB Daten belegt die Datei etwa 5 GB; schreiben Sie 60 GB, wächst sie auf 60 GB.
Das Problem beginnt in der Gegenrichtung. Löschen Sie innen ein 50 GB großes Docker-Image, meldet Linux den Platz als frei — die VHDX-Datei unter Windows bleibt jedoch exakt gleich groß. Das Format markiert die freigewordenen Blöcke lediglich als unbenutzt, ohne die Datei physisch zu kürzen. Ergebnis: `df -h` zeigt innen reichlich Platz, Windows meldet ein volles Laufwerk C.
Docker Desktop mit WSL2-Backend verdoppelt den Effekt. Docker installiert eine eigene Distribution und hält Images, Layer und Volumes in einer separaten `docker_data.vhdx`. Auf einem Entwicklungsrechner, der ein paar Jahre in Betrieb ist, überschreiten beide Dateien zusammen mühelos 100 GB.
Zuerst innen: Was vor dem Komprimieren gelöscht wird
Komprimieren ist keine Zauberei; es gibt nur Blöcke zurück, die innen tatsächlich frei sind. Der erste Schritt ist deshalb immer das Aufräumen der Distribution. Unter Debian- und Ubuntu-basierten Systemen entfernt `sudo apt clean` den heruntergeladenen Paket-Cache, `sudo apt autoremove --purge` die Abhängigkeiten, die kein Paket mehr braucht.
Bei Docker liegt der eigentliche Gewinn. `docker system df` schlüsselt auf, wie viel Images, Container, Volumes und Build-Cache jeweils belegen. `docker system prune -a --volumes` entfernt alles derzeit Ungenutzte — Achtung, das löscht auch unbenutzte Volumes, exportieren Sie also vorher jede Datenbank, die Sie behalten wollen.
Der Build-Cache ist oft der größte und zugleich am leichtesten übersehene Posten. `docker builder prune -a` trifft nur den Cache und lässt Ihre Images unberührt. In Node.js-Projekten kommen `node_modules`-Ordner innerhalb von WSL sowie `~/.npm` und `~/.cache` mit weiteren zig Gigabyte hinzu.
Komprimieren: den Platz an Windows zurückgeben
Ist innen aufgeräumt, muss der virtuelle Datenträger physisch gekürzt werden. Voraussetzung ist, dass WSL vollständig steht: `wsl --shutdown` in PowerShell ausführen und Docker Desktop schließen. Hält noch ein Prozess die Datei, scheitert das Komprimieren mit einem Zugriffsfehler.
Starten Sie in einer PowerShell mit Administratorrechten `diskpart` und führen Sie der Reihe nach aus: `select vdisk file="C:\Users\name\AppData\Local\Packages\...\ext4.vhdx"`, dann `attach vdisk readonly`, dann `compact vdisk` und zuletzt `detach vdisk`. Das schreibgeschützte Einhängen ist wichtig; schreibbar eingebunden läuft das Komprimieren nicht.
Auf Systemen mit installierten Hyper-V-Komponenten gibt es eine Einzeiler-Alternative: `Optimize-VHD -Path "Pfad\ext4.vhdx" -Mode Full`. Dieses Cmdlet fehlt in den Home-Editionen von Windows, weshalb der `diskpart`-Weg die sicherere Voreinstellung ist. Danach liegt die Dateigröße nahe an der tatsächlichen Belegung im Inneren.
Damit es nicht wieder passiert
Mit WSL 2.0 hat Microsoft Unterstützung für dünn besetzte (sparse) virtuelle Datenträger ergänzt. Tragen Sie in `%USERPROFILE%\.wslconfig` unter der Überschrift `[experimental]` die Zeile `sparseVhd=true` ein und führen Sie `wsl --shutdown` aus; neu angelegte Datenträger schrumpfen dann von selbst, sobald innen Platz frei wird. Eine bestehende Distribution wandeln Sie mit `wsl --manage <Distribution> --set-sparse true` um.
Zwei Gewohnheiten helfen zusätzlich. Erstens den Docker-Build-Cache regelmäßig leeren — `docker builder prune -a` einmal im Monat genügt auf den meisten Rechnern. Zweitens große Datenbestände auf der Windows-Seite halten und über `/mnt/c` darauf zugreifen, statt sie im WSL-Dateisystem zu speichern; so blähen die Daten den virtuellen Datenträger nicht auf.
Solche Dateien überhaupt zu bemerken ist ein eigenes Problem, denn sie erscheinen als eine einzige Datei und fallen in ordnergrößenbasierten Werkzeugen nicht auf. Das Modul Große Dateien (Large Files) von Disk Mop sortiert die größten Dateien eines Laufwerks nach Größe; `ext4.vhdx` landet dabei meist unter den ersten drei. Die Ansicht Disk Treemap zeigt dieselbe Datei als ein Rechteck, das einen großen Teil des Bildschirms einnimmt.
Häufig gestellte Fragen
Kann ich ext4.vhdx einfach löschen?
Nein. Diese Datei IST Ihre WSL-Distribution: installierte Pakete, Projekte und Datenbanken liegen alle darin. Ein Löschen entfernt die Distribution vollständig. Der richtige Weg ist, den Inhalt aufzuräumen und den Datenträger anschließend zu komprimieren.
Gefährdet das Komprimieren meine Daten?
Nein. `compact vdisk` verwirft nur ungenutzte Blöcke der Datei und fasst die Daten im Dateisystem nicht an. Trotzdem ist es gute Praxis, WSL vorher sauber mit `wsl --shutdown` zu beenden und ein Backup wichtiger Projekte zu haben.
Wo liegt die Datei von Docker Desktop?
In aktuellen Versionen unter `%LOCALAPPDATA%\Docker\wsl\disk\docker_data.vhdx`. Ältere Versionen liefern eine eigene WSL-Distribution `docker-desktop-data` mit der Datei unter `%LOCALAPPDATA%\Docker\wsl\data\ext4.vhdx`.
Muss ich mit sparseVhd nie wieder komprimieren?
Meist nicht, aber sparse-Datenträger geben Platz schrittweise frei, nicht sofort. Nach einer sehr großen Löschaktion führt manuelles Komprimieren schneller zum Ziel. Zudem gilt `sparseVhd` automatisch nur für Datenträger, die nach dem Aktivieren angelegt wurden.
Fazit
Dass WSL2 und Docker die Festplatte füllen, ist kein Fehler, sondern das Verhalten virtueller Datenträger. Die Regel ist einfach: innen aufräumen, WSL beenden, Datenträger komprimieren. Diese drei Schritte holen auf den meisten Entwicklungsrechnern 20-60 GB auf einmal zurück.
Dauerhaft hilft `sparseVhd=true` zusammen mit regelmäßigem Leeren des Build-Cache. Wenn Sie sehen möchten, was sich sonst noch angesammelt hat: Die Module Große Dateien und Disk Treemap von Disk Mop bringen genau solche Einzeldatei-Fälle in Sekunden ans Licht.
Sehen Sie, welche weiteren Riesendateien auf Ihrem Laufwerk liegen
Einmalige Zahlung für lebenslangen Zugang zu allen Funktionen. Kein Abo, keine versteckten Kosten.
Disk Mop jetzt herunterladen