WSL1 gegen WSL2: derselbe Pinguin, zwei völlig unterschiedliche Plattenrechnungen

Zwei Architekturen, zwei Speichermodelle

WSL1 hat gar keinen Linux-Kernel: Es übersetzt Linux-Systemaufrufe in Echtzeit in Windows-Aufrufe, und die Dateien liegen in einem ganz normalen Ordner — historisch %LOCALAPPDATA%\Packages\<Distro>\LocalState\rootfs —, für Windows-Werkzeuge voll einsehbar. Das macht es plattenschlank und schnell, sobald Skripte auf /mnt/c arbeiten, aber die Übersetzung ist unvollständig: Docker, systemd und alles mit exotischen Syscalls läuft nicht. WSL2 betreibt einen echten Linux-Kernel in einer leichten Hilfs-VM, was die Kompatibilität repariert — doch das komplette Dateisystem der Distribution wohnt jetzt in einer ext4.vhdx, einem virtuellen Disk-Image, das Windows einbindet, aber nicht interpretiert.

Die vhdx liegt bei Store-Installationen unter %LOCALAPPDATA%\Packages, bei neueren Installationen unter %LOCALAPPDATA%\wsl, und sie hat eine fiese Eigenschaft: Sie wächst nach Bedarf und schrumpft nie von selbst. Dateien innerhalb der Distribution zu löschen, befreit Platz auf der virtuellen Platte — aber die .vhdx-Datei behält ihren Höchststand, bis Sie sie von Hand verdichten. Ein Blick auf die Dateigröße im Explorer direkt nach einer großen Aufräumaktion in der Distribution ist die klassische Enttäuschung: Die Zahl hat sich nicht bewegt.

Wo jede Version ihre Gigabytes versteckt

Keine der beiden Versionen räumt hinter sich auf, und der Platz versickert in erstaunlich wenigen Ecken:

• Die ext4.vhdx von WSL2 — jede Distribution hat eine; ein Docker-lastiges Setup schiebt sie routinemäßig über 30 GB
• Docker Desktops eigene Datenplatte (docker_data.vhdx) nach demselben Nur-Wachstum-Prinzip
• Der WSL1-rootfs-Ordner — vergleichsweise bescheiden, aber verlassene alte Distributionen halten ihre komplette Installation
• Paket- und Build-Caches innerhalb der Distribution — apt-Caches, node_modules, target/- und build/-Ordner, die die vhdx dauerhaft aufblähen
• wsl --export-Backups und heruntergeladene Distro-Images, die in Downloads liegen und in Vergessenheit geraten

Platz zurückholen, ohne die Distribution zu beschädigen

Räumen Sie zuerst innen auf: apt autoremove und apt clean, docker system prune in Docker Desktop, npm- und pip-Cache-Leerungen — alles, was die virtuelle Platte leert, bevor Sie ihren Behälter stauchen. Danach wsl --shutdown ausführen, denn eine laufende Distribution sperrt ihre vhdx; dann das Image verdichten: Optimize-VHD mit -Mode Full, falls das Hyper-V-Werkzeugzeug installiert ist, oder diskpart mit select vdisk file="<Pfad>", attach vdisk, compact vdisk, detach vdisk auf jedem Windows. Neuere WSL-Versionen bieten wsl --manage <Distro> --set-sparse true — die vhdx gibt Platz dann automatisch frei, auf Dauer die ehrlich bessere Einstellung.

Zwei letzte Mittel verdienen ihre Namen. wsl --export packt die Distribution in ein .tar, das sich per wsl --import auf einem anderen Laufwerk entpacken lässt — der saubere Weg, eine WSL2-Installation von einer vollen C:-Platte zu holen. Und wsl --unregister <Distro> löscht die Distribution samt vhdx vollständig — dieser Befehl kennt kein Zurück, behandeln Sie ihn als das, was er ist. Nebenbei: Begrenzen Sie den Appetit der VM mit einer .wslconfig-Datei für Arbeitsspeicher und Prozessoren, sonst hält eine untätige WSL2-VM grundlos Gigabytes an RAM fest.

Fragen und Antworten

Weiterlesen