- Die Subsystemstruktur von Windows NT ist als API-Aufrufkonvertierungsschicht aufgebaut, um Programme für andere Betriebssysteme auszuführen
- WSL1 setzt diese Tradition fort und arbeitet als leichte Übersetzungsschicht, die Linux-Aufrufe in Windows-Kernelaufrufe umwandelt
- WSL2 wurde wegen Performance-Problemen auf eine vollständige Linux-VM auf Hyper-V-Basis umgestellt und führt einen echten Linux-Kernel aus
- WSL2 bietet mit dynamischem Speichermanagement, Windows-Laufwerks-Mount, GUI-Integration über WSLg und ähnlichem eine höhere Integration als eine normale VM
- Obwohl es Einschränkungen wie unbequeme Dateiverwaltung und Datenträger-Image-Abhängigkeit gibt, ist die selektive Nutzung der jeweiligen Vor- und Nachteile von WSL1 und WSL2 entscheidend
Das Subsystem-Konzept von Windows NT
- Das Subsystem (subsystem) von Windows NT bezeichnet einen Satz aus APIs und einer Aufrufkonvertierungsschicht, um Programme für andere Betriebssysteme auszuführen
- In früheren NT-Versionen existierten u. a. OS/2-Subsystem (OS2SS.EXE), POSIX-Subsystem (PSXSS.EXE) usw.
- CSRSS.EXE ist die Win32-API-Übersetzungsschicht; einige Funktionen wurden in den Kernel-Modus (
WIN32K.SYS) verschoben
- Das POSIX-Subsystem war eine Minimalimplementierung für staatliche Zertifizierungsanforderungen und wurde später durch das auf Interix basierende Windows Services for Unix ersetzt
WSL1: Übersetzungsbasierte Linux-Schicht
- Das WSL1 (Windows Subsystem for Linux) ist eine dünne Übersetzungsschicht, die Linux-Systemaufrufe in Windows-Aufrufe konvertiert
- Beim Start nutzt nur der
bash-Prozess wenige MB Speicher und wird im Task-Manager als normaler Prozess angezeigt
- Das Root-Dateisystem liegt als einzelne Dateistruktur auf NTFS, sodass der Speicher-Overhead nahezu nicht existiert
- Einschränkungen
- Eingeschränkte I/O-Leistung: Übersetzungskosten durch Unterschiede zwischen Linux- und Win32-Dateisystem-APIs
- Für die Ausführung der GUI ist ein externer X-Server erforderlich (z. B. X410)
- Keine Unterstützung für Raw-Sockets, daher sind
traceroute, nmap, tcpdump usw. nicht ausführbar
WSL2: Linux-VM auf Hyper-V-Basis
- Auf Nutzeranforderung hat Microsoft eine vollständige Linux-VM auf Hyper-V eingeführt
- Das Root-Dateisystem wird als einzelne VHDX-Datei verwaltet
- Über den Befehl
wsl --set-version "Ubuntu" 2 ist ein Wechsel zwischen WSL1 und WSL2 möglich
- Leistungseigenschaften
- Der Startvorgang ist anfangs langsamer, jedoch wird ein nativ Linux-Kernel ausgeführt
- Die Speichernutzung ist dynamisch und kann bis zu 50 % des physischen Maximalspeichers ansteigen
- Im
stress-Test steigt der Speicherverbrauch mit der Last und wird anschließend automatisch reduziert
- Bei Bedarf kann die VM mit dem Befehl
wsl --shutdown beendet werden
Integration und Grenzen von WSL2
- WSL2 stärkt im Vergleich zu traditionellen VMs die Integration mit Windows
- Automatisches Mounten von Windows-Laufwerken, Zugriff auf Linux-Laufwerke über den Pfad
\\wsl$\\, GUI-App-Ausführung über WSLg
- GUI-Apps werden über Remote-Desktop-Protokoll gestreamt; für DPI und Textskalierung sind separate Einstellungen erforderlich
- Dateiverwaltungsprobleme
- Linux-Arbeitsdaten werden innerhalb des
ext4.vhdx-Images gespeichert, was Portabilitäts- und Wiederherstellungsrisiken birgt
- Mit
wsl --unregister Distro werden alle Daten sofort gelöscht
- Bei Nutzung von Windows-Laufwerken (
/mnt/c) kommt es durch NTFS + VM-Overhead zu Leistungseinbußen
- Dateisystemprotokoll
- WSL1 nutzt
drvfs, WSL2 verwendet das 9p-Protokoll von Plan9
- Ein Bug-Fall wird erwähnt, bei dem im Konvertierungsprozess
drvfs verbleibt
- Alternativen
- Es wird empfohlen, ein separates VHDX-Image zu erzeugen und mittels
wsl --mount --vhd einzubinden, um Arbeitsdaten zu trennen
- Automatische Konfiguration in
.wslconfig ist nicht möglich, Skripte sind erforderlich
Fazit
- Die modulare Architektur von Windows NT und die stabile Kernel-ABI erhalten die Kompatibilität mit alten Treibern
- WSL1 hat den Vorteil geringer Speichernutzung, WSL2 bietet mit dem echten Linux-Kernel höhere Kompatibilität und Leistung
- WSL2 minimiert die Nachteile von VMs und verstärkt die Integration mit dem Host-Betriebssystem
- Nach klassischer Definition ist es zwar einer VM näher, hat aber als „leichtgewichtig integrierte Umgebung“ genug Grund, als Subsystem bezeichnet zu werden
Noch keine Kommentare.