Wenn Sie das Windows-Subsystem für Linux zum ersten Mal verwenden, scheint alles zu funktionieren. Sie können ein Repository klonen, Abhängigkeiten installieren, Ihre App ausführen und sich sogar davon überzeugen, dass Sie jetzt „Linux unter Windows“ haben. Dann fühlt sich etwas nicht richtig an und Sie bemerken, dass die Befehle, die sofort ausgeführt werden sollten, merklich viel Zeit in Anspruch nehmen. Paketinstallationen ziehen sich in die Länge, Dateibeobachter verhalten sich seltsam und Entwicklungsserver fühlen sich in einer Weise träge, die sich kaum auf eine einzelne Ursache zurückführen lässt. Zuerst wird WSL2 selbst dafür verantwortlich gemacht, da dies der offensichtliche Schuldige ist, aber normalerweise ist es auch der Falsche.
Das eigentliche Problem ist, wo Ihre Dateien gespeichert sind
Das Windows-Dateisystem führt zu versteckten Leistungseinbußen
Wenn sich Ihr Projekt an einem Ort befindet wie:
/mnt/c/Users/YourName/projects/my-app
Sie arbeiten nicht wirklich an einem Linux-Dateisystem. Sie arbeiten am Windows-Dateisystem, auf das über eine Übersetzungsschicht zugegriffen wird.
Dieses Detail ist leicht zu übersehen und überraschend teuer. WSL2 führt einen echten Linux-Kernel in einer kompakten virtuellen Maschine aus. In dieser Umgebung gibt es ein natives Linux-Dateisystem. Es ist schnell, konsistent und verhält sich genau so, wie es Linux-Tools erwarten.
Wenn Sie jedoch auf Dateien unter/mnt/c,/mnt/d oder einem anderen gemounteten Windows-Laufwerk zugreifen, muss jeder Dateivorgang eine Grenze zwischen Linux und Windows überschreiten. An dieser Grenze geht die Leistung verloren (leise, ohne Fehler auszulösen, was die Sache noch schlimmer macht).
Verwandte
WSL ist gut, aber es reicht mir immer noch nicht, um zu Windows zurückzukehren
Es bedarf mehr als einer virtuellen Linux-Maschine, um mich mit Copilot zufrieden zu geben.
Warum dies die Dinge tatsächlich verlangsamt
Dateiintensive Arbeitsabläufe erhöhen den Aufwand für die Dateisystemübersetzung
Moderne Entwicklungsworkflows sind extrem dateiintensiv. Überlegen Sie, was passiert, wenn Sie so etwas ausführen:
npm installpip installcargo buildnpm run dev
Diese Tools erstellen, lesen und ändern Tausende kleiner Dateien. Sie sind auf schnellen Dateisystemzugriff und vorhersehbares Verhalten angewiesen.
Auf einem nativen Linux-Dateisystem ist dies optimiert, aber auf dem Windows-Dateisystem, auf das über WSL2 zugegriffen wird, beinhaltet jeder dieser Vorgänge eine Übersetzung zwischen zwei verschiedenen Systemen.
Dadurch funktionieren die Dinge, aber alles ist nur langsamer. Manchmal ist es 2x langsamer, manchmal 10x langsamer und in manchen Fällen kann es schlimmer sein. Man merkt es nicht immer sofort, weil sich die Verlangsamung auf viele kleine Vorgänge verteilt, aber mit der Zeit summiert sie sich.
Eine der einfachsten Möglichkeiten, dieses Problem zu beobachten, ist Git. Führen Sie „git status“ oder „git checkout“ für ein großes Repository aus, das unter/mnt/c gespeichert ist, und vergleichen Sie es mit demselben Repository in Ihrem Linux-Home-Verzeichnis.
Verwandte
5 Git-Funktionen, die sich tatsächlich wie Betrug anfühlen
Diese versteckten Ecken von Git sparen Ihnen Zeit und machen Ihren Arbeitsablauf weniger mühsam.
Der Unterschied ist nicht unerheblich, da Git viele Dateisystemoperationen ausführt. Es durchsucht Verzeichnisse, überprüft Metadaten und vergleicht Dateizustände. Auf einer langsamen Dateisystembrücke wird dies schmerzhaft deutlich. Die Leute geben Git oft selbst die Schuld oder gehen davon aus, dass ihr Repository „nur groß“ ist. In Wirklichkeit verursacht die Wahl des Dateisystems den größten Schaden.
Ein weiteres häufiges Symptom ist die unzuverlässige Dateiüberwachung. Tools wie Webpack, Vite oder Nodemon sind auf Dateisystemereignisse angewiesen, um Änderungen zu erkennen. Auf einem nativen Linux-Dateisystem werden diese Ereignisse effizient übermittelt.
Über die Windows-Grenze hinaus werden die Dinge inkonsistent.
Möglicherweise sehen Sie:
- Änderungen lösen keine Neuaufbauten aus
- Verzögertes Nachladen
- Erhöhte CPU-Auslastung durch Polling-Fallbacks
Dies ist kein Fehler in Ihren Tools, sondern eine Folge der Art und Weise, wie Dateisystembenachrichtigungen zwischen Windows und Linux übersetzt werden. Verschieben Sie das Projekt in das Dateisystem von WSL2, und diese Probleme verschwinden in der Regel.
Crucial Pro Overclocking DDR5 RAM 32 GB (2 x 16 GB) 6000 MHz CL36
Marke
Entscheidend
Technologie
DDR5
Die irreführende Zweckmäßigkeit von/mnt/c
Der Komfort verbirgt die Kosten für den systemübergreifenden Zugriff
Es ist völlig verständlich, warum Menschen hier landen. Sie starten in Windows und Ihre Dateien und Ihr Editor sind dort. Es fühlt sich natürlich an, einfach von WSL2 aus über/mnt/c darauf zuzugreifen.
Dadurch entsteht die Illusion einer einheitlichen Umgebung. Ein Dateisystem, auf das sowohl von Windows als auch von Linux aus zugegriffen werden kann, außer dass es nicht einheitlich, sondern überbrückt ist und Brücken kostenpflichtig sind.
Dieses Setup eignet sich gut für gelegentlichen Dateizugriff, nicht jedoch für aktive Entwicklungs-Workloads, die von hochfrequenten Dateisystemvorgängen abhängen.
Wenn Sie an einem Linux-Dateisystem innerhalb von WSL2 arbeiten, ist der Unterschied sofort spürbar. Ihr Weg sieht so aus:
Jetzt arbeiten Sie vollständig in der Linux-Umgebung und es gibt keine Übersetzungsebene oder betriebssystemübergreifenden Overhead. Wenn Sie in diesem Verzeichnis Abhängigkeitsinstallationen ausprobieren, werden Sie feststellen, dass diese schneller abgeschlossen werden und Entwicklungsserver auch schneller starten und zuverlässig neu geladen werden.
Aber wie sieht es mit dem Zugriff von Windows aus?
Moderne Editoren unterstützen bereits Remote-Linux-Workflows
Das ist der Teil, der die Leute zögern lässt. Wenn sich Ihr Projekt in WSL2 befindet, wie öffnen Sie es in Ihrem Windows-Editor?
Die Antwort ist, dass moderne Werkzeuge dieses Problem bereits gelöst haben. Wenn Sie VS Code verwenden, können Sie mit der Remote WSL-Erweiterung Ihr Linux-Dateisystem direkt öffnen. Ihr Editor läuft unter Windows, aber die Dateien bleiben in WSL2.
Dies ist der beabsichtigte Arbeitsablauf. Es vermeidet die Leistungseinbußen teilweise (nicht vollständig), während Ihre Entwicklungserfahrung intakt bleibt. Sie können auch über den speziellen Pfad auf WSL-Dateien zugreifen:
\\wsl$\YourDistro\home\youruser\projects
Für die aktive Entwicklung ist der Remote-Integrationsansatz jedoch sauberer.
Wenn Sie möglicherweise noch/mnt/c verwenden
Einige Workloads profitieren immer noch vom Windows-Dateisystem
Fairerweise muss man sagen, dass das Windows-Dateisystem in diesem Zusammenhang nicht nutzlos ist. Es gibt gültige Anwendungsfälle wie den Zugriff auf Dokumente oder Mediendateien, die gemeinsame Nutzung einfacher Skripts zwischen Umgebungen und die Interoperabilität mit reinen Windows-Tools, aber für die aktive Entwicklung, insbesondere alles, was große Abhängigkeitsbäume oder häufige Dateioperationen beinhaltet, ist dies der falsche Ort, um Ihr Projekt zu platzieren. Es ist hilfreich, sich WSL2 nicht als „Linux in Windows“ vorzustellen, sondern als separates Linux-System, das sich gut in Windows integrieren lässt.
Sobald Sie dieses Modell übernehmen, wird die Entscheidung über das Dateisystem offensichtlich. Normalerweise würden Sie ein Linux-Projekt nicht auf einem im Netzwerk eingebundenen Dateisystem mit hoher Latenz entwickeln. Sie würden es lokal halten. In WSL2 ist das Linux-Dateisystem Ihre lokale Umgebung und das Windows-Dateisystem ist aus Linux-Sicht praktisch remote.
Die Behebung dauert nur wenige Minuten
Projekt verschieben oder in das Linux-Dateisystem klonen
Die Lösung ist nicht kompliziert. Sie müssen nur Ihr Projekt verschieben:
mv /mnt/c/Users/YourName/projects/my-app ~/projects/
Oder klonen Sie es direkt in WSL2 erneut:
git clone <repo>
~/projects/my-app
Aktualisieren Sie Ihren Editor, um den neuen Speicherort zu öffnen.
Die Leistung hängt mehr vom Standort als von der Abstimmung ab
WSL2 funktioniert am besten, wenn es als vollständige Linux-Umgebung behandelt wird, wobei die eigenen internen Grenzen respektiert werden. Sobald ein Projekt in diesem Raum stattfindet, verschwinden die meisten Reibungspunkte, die mit hybriden Arbeitsabläufen verbunden sind. Windows bleibt als Schnittstellenschicht nützlich, aber der Ausführungskontext wird wieder kohärent und die Tools verhalten sich so, wie sie sollen.
Das Interessante daran ist, wie wenig Aufwand erforderlich ist, um diesen Zustand zu erreichen. Ein Ortswechsel verändert die Leistung stärker, als es bei den meisten Konfigurationsoptimierungen jemals der Fall sein wird. Sobald dies intuitiv wird, sieht das frühere Verhalten weniger wie ein Rätsel aus, sondern eher wie eine vorhersehbare Folge der Kreuzung von Systemen, die nie für den ständigen Hin- und Herzugriff optimiert wurden.
*️⃣ Quelllink:
Dateisystem, WSL ist gut, aber es reicht mir immer noch nicht, um zu Windows zurückzukehren , 5 Git-Funktionen, die sich tatsächlich wie Betrug anfühlen , Webpack, Remote-WSL-Erweiterung ,