Die WSL 2 Dev Drive Performance ist aktuell der wichtigste Hebel, um die Geschwindigkeit deiner Entwicklungsumgebung unter Windows 11 massiv zu steigern. Erinnerst du dich an das Gefühl, wenn du npm install oder mvn install in einem großen Projekt ausführst und dir währenddessen bequem einen Kaffee kochen kannst – inklusive Bohnen mahlen? I/O-Performance, also die Geschwindigkeit, mit der Dateien geschrieben und gelesen werden, war lange Zeit der Endgegner in der hybriden Windows-Linux-Entwicklung.

Während WSL 2 innerhalb seines eigenen ext4-Containers rasend schnell ist, bricht die Leistung oft ein, sobald wir Daten auf dem Windows-Host (unter /mnt/c) bearbeiten oder riesige Mengen an kleinen Cache-Dateien (hallo node_modules!) hin- und herschieben müssen. Die Lösung, die Microsoft ab Windows 11 (22H2) eingeführt hat, nennt sich Dev Drive. In diesem Artikel zeige ich dir, wie du dieses mächtige Werkzeug nutzt.

Warum NTFS für Entwickler zur Bremse wurde

Um zu verstehen, warum wir überhaupt über die WSL 2 Dev Drive Performance sprechen müssen, ist ein kurzer technischer Exkurs nötig. Das klassische Windows-Dateisystem NTFS ist ein robustes Arbeitstier. Es ist großartig für Dokumente, Fotos und das Betriebssystem selbst. Aber es hat eine Schwäche: Metadaten-Overhead bei vielen kleinen Dateien.

Moderne Webentwicklung besteht oft aus Tausenden winziger Textdateien. Wenn du ein React-Projekt erstellst, werden zigtausend kleine Dateien entpackt, geschrieben und indiziert.

Das Problem: NTFS und der Windows Defender prüfen jeden einzelnen Schreibvorgang synchron.
Die Analogie: Stell dir vor, du möchtest 10.000 Briefe verschicken, aber bei jedem einzelnen Brief musst du zum Schalter gehen, den Ausweis zeigen und eine Unterschrift leisten. Das dauert ewig und lähmt dein System.

Der Gamechanger: ReFS und Async Scanning

Hier betritt das Dev Drive die Bühne. Es basiert nicht auf NTFS, sondern auf dem Resilient File System (ReFS). Ursprünglich für Server entwickelt, wurde es nun für Developer-Workloads optimiert, um genau diese I/O-Engpässe zu beseitigen.

Was macht es anders?

Copy-on-Write (CoW): Daten werden intelligenter und schneller geschrieben, was besonders beim Duplizieren von Dateien (z. B. beim Kopieren von Projekten) Zeit spart.
Performance Mode für Defender: Das ist der eigentliche Clou für die WSL 2 Dev Drive Performance. Auf einem Dev Drive scannt der Microsoft Defender asynchron.
- NTFS: „Halt! Ich muss diese Datei prüfen, bevor du sie schreiben darfst.“
- Dev Drive: „Schreib die Datei ruhig schon mal, ich schaue sie mir gleich im Hintergrund an.“

Laut Benchmarks von Microsoft und unabhängigen Tests kann sich die Build-Zeit für I/O-lastige Szenarien um bis zu 30 % verbessern. Für uns WSL-Nutzer bedeutet das: Wenn wir unsere Projekte oder zumindest unsere globalen Caches auf ein Dev Drive auslagern, profitieren wir von dieser Geschwindigkeit – selbst wenn wir aus der Linux-Umgebung darauf zugreifen.

Voraussetzungen: Ist dein PC bereit?

Bevor wir loslegen, ein kurzer System-Check. Das Dev Drive ist ein Feature für Windows 11.

OS: Windows 11 Build 22621.2338 oder höher (22H2/23H2).
RAM: Mindestens 8 GB (16 GB empfohlen, da ReFS etwas speicherhungriger ist als NTFS).
Speicherplatz: Mindestens 50 GB freier Platz für die virtuelle Festplatte (VHD).

Hast du die Voraussetzungen erfüllt? Dann lass uns im nächsten Abschnitt die „Hardware“ einrichten und dein System beschleunigen.

Schritt-für-Schritt: Dein erstes Dev Drive erstellen

Die Einrichtung ist erstaunlich unkompliziert, da Microsoft sie direkt in die Einstellungen-App integriert hat. Du musst nicht mehr mit kryptischen PowerShell-Befehlen hantieren, um die WSL 2 Dev Drive Performance zu aktivieren.

Öffne die Einstellungen in Windows.
Navigiere zu System > Speicher > Erweiterte Speichereinstellungen > Datenträger & Volumes.
Klicke auf den Button "Dev Drive erstellen".

Windows wird dich nun durch einen Assistenten führen. Du hast meistens drei Optionen:

Neue VHD erstellen: (Empfohlen) Erstellt eine virtuelle Festplattendatei auf deinem vorhandenen Laufwerk. Das ist am sichersten und flexibelsten.
Partition verkleinern: Zwackt echten Platz von C: ab (riskanter, nur für Profis).
Nicht zugewiesener Speicher: Wenn du eine leere SSD hast.

Wähle die VHD-Option. Gib dem Kind einen Namen (z.B. DevDrive), eine Größe (z.B. 50 GB) und – ganz wichtig – den Laufwerksbuchstaben. In der Entwickler-Community hat sich Z: oder D: etabliert. Ich nutze in diesem Beispiel D:.

Nach Abschluss der Formatierung (was dank ReFS blitzschnell geht), hast du ein neues Laufwerk im Explorer. Das Icon unterscheidet sich leicht – ein kleines Symbol zeigt an, dass dies kein gewöhnliches Volume ist ("Trusted Volume").

Die Brücke schlagen: Dev Drive in WSL 2 nutzen

Jetzt haben wir ein Hochleistungs-Laufwerk unter Windows. Aber wie kommt unser Linux (Ubuntu/Debian) da ran? WSL 2 mountet Windows-Laufwerke automatisch unter /mnt/. Dein neues Dev Drive ist also sofort unter /mnt/d verfügbar.

Wir prüfen zunächst, ob es da ist:

ls -la /mnt/d

Siehst du die Dateien? Perfekt. Jetzt geht es an die Optimierung.

Strategie 1: Projekte verschieben (Der Hybrid-Ansatz)

Der einfachste Weg zur Steigerung der WSL 2 Dev Drive Performance ist, deine Projekte, die du sowohl unter Windows (z.B. mit VS Code GUI) als auch unter Linux bearbeitest, auf das Dev Drive zu schieben.

# Erstelle einen Ordner auf dem Dev Drive
mkdir -p /mnt/d/projects
# Navigiere dorthin
cd /mnt/d/projects
# Clone ein Repo zum Testen
git clone https://github.com/dein-user/dein-repo.git

Wenn du jetzt hier npm install ausführst, greift der asynchrone Virenscan von Windows. Die I/O-Bremse ist gelöst.

Wichtiger Hinweis zur Dateisystem-Performance: Auch mit Dev Drive bleibt die goldene Regel der WSL bestehen: Linux-Dateisysteme (ext4) sind für reine Linux-Operationen immer noch schneller als gemountete Windows-Laufwerke (9P-Protokoll). Das Dev Drive ist jedoch massiv schneller als ein normales NTFS-Laufwerk. Es schließt die Lücke zwischen „unbenutzbar langsam“ und „akzeptabel schnell“ für Cross-OS-Dateien.

Strategie 2: Package-Caches zentralisieren

Hier wird es richtig interessant. Selbst wenn dein Code im WSL-Filesystem (~/projects) liegt, kannst du das Dev Drive nutzen, um globale Caches auszulagern. Warum? Weil diese Caches oft riesig werden und den wertvollen Platz in deiner WSL-VHDX aufblähen.

Beispiel Node.js / NPM Cache umleiten:

Erstelle einen Cache-Ordner auf dem Dev Drive:

# In PowerShell (Admin)
New-Item -ItemType Directory -Force -Path "D:\caches\npm"

Konfiguriere NPM in der WSL so, dass es diesen Ordner nutzt:

npm config set cache /mnt/d/caches/npm

Ab sofort landen alle heruntergeladenen Pakete auf dem schnellen ReFS-Laufwerk. Das entlastet deine virtuelle Linux-Festplatte und nutzt die überlegene WSL 2 Dev Drive Performance für Schreibvorgänge, die nicht zwingend im Linux-Dateisystem liegen müssen.

Praxis-Tipp: Bestehende WSL-Distro auf das Dev Drive umziehen

Du hast deine Ubuntu-Installation über Monate perfektioniert und möchtest nicht bei Null anfangen? Kein Problem. Wir können deine komplette Distro inklusive aller Dateien auf das Dev Drive verschieben, um die volle WSL 2 Dev Drive Performance auch für dein Betriebssystem zu nutzen.

Warnung: Mache vorher ein Backup deiner Daten!

Schritt 1: Status prüfen & herunterfahren

wsl --list --verbose
wsl --shutdown

Schritt 2: Der Export (Der Umzugskarton) Wir exportieren das Dateisystem in eine Datei direkt auf das Dev Drive (D:).

wsl --export Ubuntu-22.04 D:\wsl-backup.tar

Schritt 3: Aufräumen Wir löschen die alte Registrierung auf C:, um Speicherplatz freizugeben.

wsl --unregister Ubuntu-22.04

Schritt 4: Import auf das Dev Drive Wir importieren das Backup in einen neuen Ordner auf dem Dev Drive.

New-Item -ItemType Directory -Force -Path "D:\WSL\Ubuntu"
wsl --import Ubuntu-22.04 D:\WSL\Ubuntu D:\wsl-backup.tar

Schritt 5: User wiederherstellen Nach dem Import bist du oft root. Setze deinen Standard-User in der /etc/wsl.conf:

[user]
default=dein-username

Nach einem Neustart (wsl --terminate Ubuntu-22.04) läuft deine gesamte Distro nun auf ReFS!

Trust-Level: Dem Defender vertrauen

Obwohl das Dev Drive standardmäßig im „Performance Mode“ läuft, kannst du prüfen, ob der Status korrekt ist. Ein Dev Drive muss als „Trusted“ gelten, damit der Virenscanner sich zurückhält. Sollte sich das ändern (z.B. wenn du die VHD auf einen anderen PC kopierst), fällt der Schutz auf das normale (langsame) Niveau zurück.

Prüfe den Status in der PowerShell:

fsutil devdrv query D:

Einordnung aus der Praxis

Das Dev Drive ist kein Allheilmittel, aber es löst den größten Reibungspunkt zwischen Windows-Sicherheit und Linux-Dateimengen. Ich nutze das Setup mittlerweile so: Reine Linux-Projekte bleiben im WSL-Home (~), aber alle Caches (Maven, Gradle, NPM) und Cross-Platform-Projekte liegen auf dem Dev Drive (/mnt/d). Das Ergebnis ist ein spürbar flüssigeres System und ein leiserer Lüfter.

#dev-drive

WSL 2 Cache-Beschleunigung mit dem Windows 11 „Dev Drive“ (ReFS)