Umieszczanie projektów WSL2 na dysku Windows zabija wydajność — oto dlaczego

Kiedy po raz pierwszy zaczynasz korzystać z Windows Subsystem for Linux, wszystko wydaje się działać. Możesz sklonować repozytorium, zainstalować zależności, uruchomić swoją aplikację, a nawet przekonać się, że teraz masz „Linux na Windowsie.”

Wtedy coś wydaje się nie tak i zauważasz, że polecenia, które powinny być wykonywane natychmiast, zabierają zauważalnie więcej czasu. Instalacje pakietów ciągną się, obserwatory plików zachowują się dziwnie, a serwery deweloperskie działają ociężale w sposób, który trudno przypisać jakiejkolwiek pojedynczej przyczynie. Na początku obwinia się za to WSL2, ponieważ jest to oczywisty winowajca, ale zazwyczaj jest to również niewłaściwe.

Prawdziwy problem polega na tym, gdzie znajdują się twoje pliki

System plików Windows wprowadza ukrytą karę wydajności

Jeśli Twój projekt znajduje się w miejscu takim jak:

/mnt/c/Users/YourName/projects/my-app

Nie pracujesz naprawdę na systemie plików Linuksa. Pracujesz na systemie plików Windows, do którego dostęp uzyskujesz przez warstwę tłumaczącą.

Ten szczegół jest łatwy do przeoczenia i zaskakująco kosztowny. WSL2 uruchamia prawdziwe jądro Linuksa wewnątrz lekkiej maszyny wirtualnej. W tym środowisku istnieje natywny system plików Linuksa. Jest szybki, spójny i zachowuje się dokładnie tak, jak oczekują narzędzia Linuksa.

Jednak gdy uzyskujesz dostęp do plików w /mnt/c, /mnt/d lub na jakimkolwiek zamontowanym dysku Windows, każda operacja na plikach musi przekroczyć granicę między Linuksem a Windowsem. To właśnie ta granica jest miejscem, gdzie wydajność drastycznie spada (cicho, bez wyrzucania błędów, co czyni to jeszcze gorszym).

Dlaczego to faktycznie spowalnia rzeczy

Duże obciążenia workflow plików zwiększają narzut tłumaczenia systemu plików

Nowoczesne przepływy pracy w rozwoju są niezwykle obciążone plikami. Pomyśl o tym, co się dzieje, gdy uruchamiasz coś takiego jak:

npm install
pip install
cargo build
npm run dev

Te narzędzia tworzą, odczytują i modyfikują tysiące małych plików. Polegają na szybkim dostępie do systemu plików i przewidywalnym zachowaniu.

Na natywnym systemie plików Linuxa jest to zoptymalizowane, ale na systemie plików Windows dostępnym przez WSL2 każda z tych operacji wiąże się z tłumaczeniem między dwoma różnymi systemami.

W rezultacie wszystko działa, ale wszystko jest po prostu wolniejsze. Czasami jest 2 razy wolniejsze, czasami 10 razy wolniejsze, a w niektórych przypadkach może być jeszcze gorzej. Nie zawsze od razu to zauważasz, ponieważ spowolnienie jest rozłożone na wiele małych operacji, ale z czasem się sumuje.

Jednym z najprostszych sposobów, aby zaobserwować ten problem, jest użycie Git. Uruchom git status lub git checkout w dużym repozytorium przechowywanym w /mnt/c i porównaj to z tym samym repozytorium w katalogu domowym Linuksa.

Różnica nie jest subtelna, ponieważ Git wykonuje wiele operacji na systemie plików. Skanuje katalogi, sprawdza metadane i porównuje stany plików. Na wolnym mostku systemu plików staje się to boleśnie oczywiste. Ludzie często obwiniają samego Gita lub zakładają, że ich repozytorium jest po prostu „duże”. W rzeczywistości to wybór systemu plików powoduje większość problemów.

Innym częstym objawem jest zawodność obserwacji plików. Narzędzia takie jak webpack, Vite czy nodemon polegają na zdarzeniach systemu plików do wykrywania zmian. Na natywnym systemie plików Linux te zdarzenia są dostarczane wydajnie.

Po drugiej stronie granicy systemu Windows, rzeczy stają się niespójne.

Możesz zobaczyć:

• Zmiany nie wywołujące przebudowy
• Opóźnione przeładowania
• Zwiększone użycie procesora spowodowane przez mechanizmy zapasowe odpytywania

To nie jest błąd w twoich narzędziach, lecz konsekwencja sposobu, w jaki powiadomienia systemu plików są przekładane między Windows a Linux. Przenieś projekt do systemu plików WSL2, a te problemy zwykle znikają.

Wprowadzająca w błąd wygoda /mnt/c

Wygoda ukrywa koszty dostępu między systemami

Całkowicie zrozumiałe jest, dlaczego ludzie tu trafiają. Zaczynasz w Windows, a twoje pliki i edytor są tam. Naturalnie wydaje się po prostu uzyskać do nich dostęp z WSL2 przez /mnt/c.

Daje to złudzenie jednolitego środowiska. Jeden system plików, dostępny zarówno z Windows, jak i Linux, z wyjątkiem tego, że nie jest jednolity, lecz mostkowany, a mostki mają koszty.

Ta konfiguracja jest odpowiednia dla okazjonalnego dostępu do plików, ale nie jest odpowiednia dla aktywnych obciążeń rozwojowych, które zależą od operacji na systemie plików o wysokiej częstotliwości.

Kiedy pracujesz na systemie plików Linux w WSL2, różnica jest natychmiastowa. Twoja ścieżka wygląda tak:

Teraz działasz całkowicie w środowisku Linux i nie ma żadnej warstwy tłumaczenia ani narzutu związanego z innym systemem operacyjnym. W tym katalogu, jeśli spróbujesz instalacji zależności, zauważysz, że przebiegają one szybciej, a serwery deweloperskie również uruchamiają się szybciej i przeładowują niezawodnie.

A co z dostępem z Windows?

Nowocześni edytorzy już obsługują zdalne przepływy pracy w systemie Linux

To jest ta część, która sprawia, że ludzie się wstrzymują. Jeśli Twój projekt znajduje się w WSL2, jak otwierasz go w swoim edytorze Windows?

Odpowiedź brzmi, że nowoczesne narzędzia już to rozwiązują. Jeśli używasz VS Code, rozszerzenie Remote WSL pozwala na bezpośrednie otwarcie systemu plików Linux. Twój edytor działa w Windows, ale pliki pozostają w WSL2.

To jest zamierzony przepływ pracy. W pewnym stopniu unika (nie całkowicie) utraty wydajności, jednocześnie zachowując nienaruszone doświadczenie programistyczne. Możesz również uzyskać dostęp do plików WSL przez specjalną ścieżkę:

\\wsl$\YourDistro\home\youruser\projects

Kiedy możesz nadal używać /mnt/c

Niektóre obciążenia wciąż korzystają z systemu plików Windows

Szczerze mówiąc, system plików Windows nie jest bezużyteczny w tym kontekście. Istnieją uzasadnione przypadki użycia, takie jak dostęp do dokumentów czy plików multimedialnych, udostępnianie prostych skryptów między środowiskami oraz współdziałanie z narzędziami tylko dla Windows, ale do aktywnego rozwoju, szczególnie przy dużych drzewach zależności lub częstych operacjach na plikach, jest to niewłaściwe miejsce na umieszczenie projektu. Warto myśleć o WSL2 nie jako o "Linuxie w Windows," ale jako o osobnym systemie Linux, który przypadkowo dobrze integruje się z Windows.

Gdy przyjmiesz ten model, decyzja dotycząca systemu plików stanie się oczywista. Normalnie nie rozwijałbyś projektu Linuksa na systemie plików zamontowanym w sieci o wysokiej latencji. Trzymałbyś go lokalnie. W WSL2 system plików Linuksa jest Twoim lokalnym środowiskiem, a system plików Windows jest z perspektywy Linuksa de facto zdalny.

Naprawienie tego zajmuje minuty

Przenieś projekt lub klon w systemie plików Linux

Rozwiązanie nie jest skomplikowane. Musisz po prostu przenieść swój projekt:

mv /mnt/c/Users/YourName/projects/my-app ~/projects/ 

Lub sklonuj go bezpośrednio w WSL2:

git clone <repo>  ~/projects/my-app 

Zaktualizuj swój edytor, aby otworzyć nowe miejsce.

Wydajność zależy bardziej od lokalizacji niż od strojenia

WSL2 działa najlepiej, gdy traktuje się go jako pełne środowisko Linuksa z poszanowaniem jego własnych wewnętrznych granic. W momencie, gdy projekt znajduje się w tej przestrzeni, większość problemów związanych z hybrydowymi przepływami pracy znika. Windows pozostaje użyteczny jako warstwa interfejsu, ale kontekst wykonywania staje się ponownie spójny, a narzędzia zachowują się tak, jak zostały zaprojektowane.

Ciekawą częścią jest to, jak niewielki wysiłek jest potrzebny, aby osiągnąć ten stan. Zmiana lokalizacji wpływa na wydajność bardziej niż większość strojenia konfiguracji kiedykolwiek. Gdy stanie się to intuicyjne, wcześniejsze zachowanie zaczyna wyglądać mniej jak tajemnica, a bardziej jak przewidywalna konsekwencja przekraczania systemów, które nigdy nie były optymalizowane pod stały dostęp tam i z powrotem.