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

WSL 2 Cache-Beschleunigung mit dem Windows 11 „Dev Drive“
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/dSiehst 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.gitWenn 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/npmAb 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 --shutdownSchritt 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.tarSchritt 3: Aufräumen Wir löschen die alte Registrierung auf C:, um Speicherplatz freizugeben.
wsl --unregister Ubuntu-22.04Schritt 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.tarSchritt 5: User wiederherstellen Nach dem Import bist du oft root. Setze deinen Standard-User in der /etc/wsl.conf:
[user]
default=dein-usernameNach 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.
Teil der Serie
WSL2 für Webentwicklung unter Windows
Moderne WSL 2 Webentwicklung unter Windows Pillar
WSL2 installieren unter Windows 11: Der ultimative Guide für Webentwickler (2025)
Ubuntu auf WSL2 konfigurieren
Terminal konfigurieren unter WSL2
PHP & Node.js auf WSL2: Das Triebwerk für professionelle Workflows 2025
Webserver & Datenbanken unter WSL2 (Apache, Nginx, MySQL, PostgreSQL)
VS Code & WSL2: Das ultimative Setup für professionelle Webentwicklung unter Windows
Docker unter WSL2: Containerisierung ohne Reibungsverluste
WSL 2 Performance-Tuning & Troubleshooting – Wenn der RAM-Hunger kickt
Git-Workflow unter WSL2 – schnell, sicher und stabil
WSL 2 im Unternehmensnetzwerk: So bändigst du Proxys, VPNs & SSL
WSL 2 vmmem bändigen: Der Performance-Guide für professionelle Entwickler
WSL 2 Speicherplatz freigeben: So zähmst du die VHDX-Datei
WSL 2 Cache-Beschleunigung mit dem Windows 11 „Dev Drive“ (ReFS)
Häufig gestellte Fragen (FAQ)
Vorschau auf Teil 14: WSL 2 Professionelle Backup- & Disaster-Recovery-Strategien
Jetzt, wo dein System rennt wie ein Formel-1-Wagen, müssen wir über den Airbag sprechen. Was passiert, wenn du dir deine Konfiguration zerschießt? Oder wenn ein Windows-Update deine VHD korrumpiert? Im nächsten Teil verlassen wir die Performance-Ebene und gehen zur Sicherheit über. Ich zeige dir, wie du Snapshots deiner WSL erstellst, wie du komplette Entwicklungsumgebungen exportierst und eine "Time-Machine"-ähnliche Strategie für dein Linux-Subsystem aufbaust. Keine Angst mehr vor sudo rm -rf!

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.


