Du möchtest effektiv WSL 2 Speicherplatz freigeben, weil Windows plötzlich „Laufwerk C: fast voll“ meldet? Keine Sorge, das ist ein bekanntes Phänomen bei der Webentwicklung unter Windows, und die Lösung ist einfacher, als du denkst.
Nach über 25 Jahren Coding-Erfahrung weiß ich: Es ist fast immer die Datei ext4.vhdx. Sie wächst dynamisch mit jeder installierten Library, vergisst aber leider das Schrumpfen. Hier zeige ich dir, wie du deine SSD in wenigen Minuten bereinigst. Bevor du manuelle Eingriffe an der virtuellen Festplatte vornimmst, erstelle zur Sicherheit unbedingt ein Backup deiner WSL 2 Umgebung.
Das Problem mit der VHDX-Datei
WSL 2 speichert dein gesamtes Linux-System in einem Container. Diese Datei verhält sich wie ein Luftballon in einer starren Kiste:
Speicherst du Daten in Linux, dehnt sich der Ballon aus.
Die Datei auf deinem Windows-PC wächst sofort mit.
Löschst du nun Dateien in Linux, zieht sich der Ballon zwar innen zusammen. Die äußere Hülle (die VHDX-Datei) bleibt jedoch auf ihrer maximalen Größe. Der Platz bleibt blockiert. Deshalb musst du manuell eingreifen, wenn du WSL 2 Speicherplatz freigeben willst.
Schritt 1: Der Docker-Müll muss weg
Bevor wir die Festplatte verkleinern, müssen wir aufräumen. Docker ist oft der größte Speicherfresser. Alte Images und abgebrochene Builds belegen unnötig Platz.
Führe diesen Befehl in deinem WSL-Terminal aus:
Bash
docker system prune -a--volumes
Dieser Schritt ist essenziell. Er entfernt den Datenmüll im Inneren des Ballons, damit das Komprimieren danach maximal wirkt.
Tipp: Diese Admin-Befehle kannst du dir mit Sudo für Windows deutlich vereinfachen, ohne ständig die Konsole wechseln zu müssen.
Schritt 2: VHDX komprimieren mit Diskpart
Jetzt holen wir uns den Speicherplatz physikalisch zurück. Wir zwingen die VHDX-Datei, sich an den tatsächlichen Inhalt anzupassen.
So funktioniert die Kurzfassung:
WSL beenden: Öffne die PowerShell und tippe wsl --shutdown.
Tool starten: Öffne die PowerShell als Administrator und starte diskpart.
Datei wählen: Wähle deine Datei mit select vdisk file="C:\Pfad\zu\deiner\ext4.vhdx".
Verkleinern: Tippe compact vdisk.
Du wirst staunen: Oft lassen sich so 20 bis 50 Gigabyte sofort zurückgewinnen.
Automatisch Speicher sparen mit sparseVHD
Musst du das jetzt jeden Monat machen? Zum Glück nicht mehr. Es gibt eine Einstellung namens „Sparse VHD“.
Füge folgenden Eintrag in deine .wslconfig Datei in deinem Windows-Benutzerprofil ein:
Bash
[wsl2]sparseVHD=true
Damit gibt WSL 2 freigegebene Blöcke automatisch an Windows zurück. Das ist die beste Prävention gegen volle Festplatten.
Fazit: Wartung ist Pflicht
WSL 2 ist ein fantastisches Werkzeug für Entwickler. Es ist schnell und stabil. Aber es ist nicht wartungsfrei. Wer die ext4.vhdx ignoriert, hat bald eine volle Festplatte.
Mit den oben genannten Schritten kannst du jederzeit sicher WSL 2 Speicherplatz freigeben und Performance-Probleme vermeiden. Mach diese Routine zu einem festen Teil deines Workflows.
WSL 2 Festplatten (VHDX) sind dynamisch: Sie wachsen automatisch, wenn du Dateien hinzufügst. Wenn du Dateien löschst, wird der Platz intern in Linux frei, aber die Dateigröße unter Windows schrumpft nicht automatisch zurück.
Nein! Wenn du die ext4.vhdx Datei löschst, verlierst du deine komplette Linux-Installation inklusive aller Projekte, Datenbanken und Konfigurationen. Nutze stattdessen compact vdisk via Diskpart.
Dieser Befehl beendet die WSL-Instanz und die leichte virtuelle Maschine im Hintergrund vollständig. Das ist notwendig, damit Windows Zugriff auf die VHDX-Datei erhält, um sie zu komprimieren. Es gehen dabei keine gespeicherten Daten verloren.
Ja, diese Funktion ist offiziell von Microsoft implementiert. Sie sorgt dafür, dass ungenutzte Speicherblöcke kontinuierlich an das Windows-Dateisystem zurückgegeben werden, ohne dass du manuell eingreifen musst.
Ausblick auf Teil 13: Cache-Beschleunigung mit dem Windows-11-„Dev Drive“
Im nächsten Teil verlassen wir die reine Speicherverwaltung und gehen einen Schritt weiter in Richtung I/O-Performance. Es geht um den Windows-11-„Dev Drive“ – ein Feature, das viel verspricht, aber in der Praxis oft falsch eingesetzt wird.
Wir klären, wann ein Dev Drive wirklich messbare Vorteile bringt, welche Workloads davon profitieren und warum es kein Ersatz für sauberes WSL2-Storage-Design ist. Anhand konkreter Beispiele zeige ich, wie sich Cache- und Build-Zeiten beeinflussen lassen – und wo die Grenzen dieses Ansatzes liegen.
Aus meiner Erfahrung aus zahlreichen Performance-Audits bei Entwickler-Setups sehe ich immer wieder denselben Fehler: neue Features werden aktiviert, ohne die zugrunde liegenden Datenpfade zu verstehen. Genau hier setzt Teil 13 an – pragmatisch, messbar und ohne Marketing-Versprechen.
Über den Autor
Dietrich Bojko
Senior Webentwickler
Webinteger arbeitet seit vielen Jahren produktiv mit
Linux-basierten Entwicklungsumgebungen unter Windows. Der Fokus liegt auf
performanten Setups mit WSL 2, Docker, PHP, Node.js und modernen
Build-Tools in realen Projekten
– nicht auf theoretischen Beispielkonfigurationen.
Die Artikel dieser Serie entstehen direkt aus dem täglichen Einsatz in
Kunden- und Eigenprojekten und dokumentieren bewusst auch typische Fehler,
Engpässe und bewährte Workarounds.
Webseite besuchen
