Lorsque vous commencez à utiliser le sous-système Windows pour Linux, tout semble fonctionner. Vous pouvez cloner un référentiel, installer des dépendances, exécuter votre application et même vous convaincre que vous disposez désormais de « Linux sur Windows ». Ensuite, quelque chose ne va pas et vous remarquez que les commandes qui devraient être instantanées prennent un temps considérable. Les installations de packages traînent, les observateurs de fichiers se comportent étrangement et les serveurs de développement semblent lents d’une manière difficile à attribuer à une seule cause. Au début, cela est imputé à WSL2 lui-même, car c’est le coupable évident, mais ce n’est généralement pas le bon.
Le vrai problème est l’endroit où se trouvent vos fichiers
Le système de fichiers Windows introduit une pénalité de performances cachée
Si votre projet se situe quelque part comme :
/mnt/c/Users/YourName/projects/my-app
Vous ne travaillez pas vraiment sur un système de fichiers Linux. Vous travaillez sur le système de fichiers Windows, accessible via une couche de traduction.
Ce détail est facile à manquer et étonnamment cher. WSL2 exécute un véritable noyau Linux dans une machine virtuelle légère. Dans cet environnement, il existe un système de fichiers Linux natif. Il est rapide, cohérent et se comporte exactement comme les outils Linux l’attendent.
Cependant, lorsque vous accédez à des fichiers sous /mnt/c ,/mnt/d ou à tout lecteur Windows monté, chaque opération sur les fichiers doit franchir une frontière entre Linux et Windows. Cette limite est l’endroit où les performances vont mourir (tranquillement, sans commettre d’erreurs, ce qui ne fait qu’empirer les choses).
Connexes
WSL c’est bien, mais ce n’est toujours pas suffisant pour revenir à Windows
Il me faudra plus qu’une machine virtuelle Linux pour m’habituer à Copilot.
Pourquoi cela ralentit les choses
Les flux de travail lourds sur les fichiers amplifient la surcharge de traduction du système de fichiers
Les workflows de développement modernes sont extrêmement lourds en fichiers. Pensez à ce qui se passe lorsque vous exécutez quelque chose comme :
npm installpip installcargo buildnpm run dev
Ces outils créent, lisent et modifient des milliers de petits fichiers. Ils s’appuient sur un accès rapide au système de fichiers et un comportement prévisible.
Sur un système de fichiers Linux natif, ceci est optimisé, mais sur le système de fichiers Windows accessible via WSL2, chacune de ces opérations implique une traduction entre deux systèmes différents.
Du coup, les choses fonctionnent, mais tout est juste plus lentement. Parfois, c’est 2 fois plus lent, parfois 10 fois plus lent et, dans certains cas, cela peut être pire. On ne le remarque pas toujours immédiatement, car le ralentissement est réparti sur de nombreuses petites opérations, mais avec le temps, il s’accumule.
L’un des moyens les plus simples d’observer ce problème consiste à utiliser Git. Exécutez git status ou git checkout sur un grand référentiel stocké sous/mnt/c et comparez-le au même référentiel dans votre répertoire personnel Linux.
Connexes
5 fonctionnalités de Git qui donnent vraiment l’impression de tricher
Ces coins cachés de Git vous feront gagner du temps et rendront votre flux de travail moins pénible.
La différence n’est pas subtile, car Git effectue de nombreuses opérations sur le système de fichiers. Il analyse les répertoires, vérifie les métadonnées et compare les états des fichiers. Sur un pont de système de fichiers lent, cela devient douloureusement évident. Les gens blâment souvent Git lui-même ou supposent que leur référentiel est « tout simplement volumineux ». En réalité, le choix du système de fichiers fait la plupart des dégâts.
Un autre symptôme courant est la surveillance peu fiable des fichiers. Des outils comme webpack, Vite ou nodemon dépendent des événements du système de fichiers pour détecter les modifications. Sur un système de fichiers Linux natif, ces événements sont livrés efficacement.
Au-delà des limites de Windows, les choses deviennent incohérentes.
Vous pourriez voir :
- Les modifications ne déclenchent pas les reconstructions
- Recharges retardées
- Augmentation de l’utilisation du processeur suite aux erreurs d’interrogation
Il ne s’agit pas d’un bug dans vos outils mais d’une conséquence de la façon dont les notifications du système de fichiers sont traduites entre Windows et Linux. Déplacez le projet dans le système de fichiers de WSL2 et ces problèmes ont tendance à disparaître.
Crucial Pro Overclocking DDR5 RAM 32 Go (2 x 16 Go) 6 000 MHz CL36
Marque
Crucial
Technologie
DDR5
La commodité trompeuse de/mnt/c
La commodité masque le coût de l’accès à plusieurs systèmes
On comprend tout à fait pourquoi les gens se retrouvent ici. Vous démarrez sous Windows et vos fichiers et votre éditeur sont là. Il semble naturel d’y accéder simplement depuis WSL2 via/mnt/c.
Cela vous donne l’illusion d’un environnement unifié. Un système de fichiers, accessible à la fois depuis Windows et Linux, sauf qu’il n’est pas unifié mais ponté, et les ponts ont des coûts.
Cette configuration convient à un accès occasionnel aux fichiers, mais elle ne convient pas aux charges de travail de développement actives qui dépendent d’opérations à haute fréquence sur le système de fichiers.
Lorsque vous travaillez sur un système de fichiers Linux dans WSL2, la différence est immédiate. Votre chemin ressemble à ceci :
Vous travaillez désormais entièrement dans l’environnement Linux et il n’y a pas de couche de traduction ni de surcharge entre les systèmes d’exploitation. Dans ce répertoire, si vous essayez des installations de dépendances, vous remarquerez qu’elles se terminent plus rapidement et que les serveurs de développement démarrent également plus rapidement et se rechargent de manière fiable.
Mais qu’en est-il de l’accès depuis Windows ?
Les éditeurs modernes prennent déjà en charge les workflows Linux à distance
C’est la partie qui fait hésiter les gens. Si votre projet réside dans WSL2, comment l’ouvrir dans votre éditeur Windows ?
La réponse est que les outils modernes ont déjà résolu ce problème. Si vous utilisez VS Code, l’extension Remote WSL vous permet d’ouvrir directement votre système de fichiers Linux. Votre éditeur fonctionne sous Windows, mais les fichiers restent dans WSL2.
Il s’agit du flux de travail prévu. Cela évite quelque peu (pas complètement) la pénalité de performances tout en gardant votre expérience de développement intacte. Vous pouvez également accéder aux fichiers WSL via le chemin spécial :
\\wsl$\YourDistro\home\youruser\projects
Mais pour un développement actif, l’approche d’intégration à distance est plus propre.
Quand vous pourriez encore utiliser /mnt/c
Certaines charges de travail bénéficient toujours du système de fichiers Windows
Pour être honnête, le système de fichiers Windows n’est pas inutile dans ce contexte. Il existe des cas d’utilisation valables tels que l’accès à des documents ou à des fichiers multimédias, le partage de scripts simples entre environnements et l’interopérabilité avec des outils Windows uniquement, mais pour un développement actif, en particulier tout ce qui implique de grandes arborescences de dépendances ou des opérations de fichiers fréquentes, ce n’est pas le bon endroit pour placer votre projet. Il est utile de considérer WSL2 non pas comme « Linux à l’intérieur de Windows », mais comme un système Linux distinct qui s’intègre bien à Windows.
Une fois que vous avez adopté ce modèle, la décision concernant le système de fichiers devient évidente. Vous ne développeriez normalement pas un projet Linux sur un système de fichiers monté en réseau avec une latence élevée. Vous le garderiez local. Dans WSL2, le système de fichiers Linux est votre environnement local et le système de fichiers Windows est effectivement distant du point de vue de Linux.
Le réparer prend quelques minutes
Déplacer le projet ou le cloner dans le système de fichiers Linux
La solution n’est pas compliquée. Il vous suffit de déplacer votre projet :
mv /mnt/c/Users/YourName/projects/my-app ~/projects/
Ou reclonez-le directement dans WSL2 :
git clone <repo>
~/projects/my-app
Mettez à jour votre éditeur pour ouvrir le nouvel emplacement.
Les performances dépendent davantage de l’emplacement que du réglage
WSL2 fonctionne mieux lorsqu’il est traité comme un environnement Linux complet avec ses propres limites internes respectées. Dès qu’un projet vit dans cet espace, la plupart des frictions associées aux flux de travail hybrides s’estompent. Windows reste utile en tant que couche d’interface, mais le contexte d’exécution redevient cohérent et les outils se comportent comme ils ont été conçus pour se comporter.
Ce qui est intéressant, c’est le peu d’efforts nécessaires pour atteindre cet état. Un changement d’emplacement modifie les performances plus que la plupart des réglages de configuration ne le feront jamais. Une fois que cela devient intuitif, le comportement antérieur commence à ressembler moins à un mystère qu’à une conséquence prévisible de systèmes de croisement qui n’ont jamais été optimisés pour un accès constant.
*️⃣ Lien source :
système de fichiers, WSL est bon, mais ce n’est toujours pas suffisant pour revenir à Windows , 5 fonctionnalités Git qui donnent vraiment l’impression de tricher , webpack, Extension WSL distante ,