Чому npm install на диску Windows у WSL працює повільно?

Менеджери пакетів, як-от npm чи pip, створюють під час встановлення тисячі дрібних файлів. Коли ці файли записуються через межу ОС на диск Windows з NTFS, кожен окремий файл зазнає витрат на трансляцію, що спричиняє серйозні вузькі місця в продуктивності.

Продуктивність файлової системи WSL: чому доступ через межу ОС сповільнює ваш код

Q: Де зберігати файли проєкту під час роботи з WSL?

Файли проєкту варто зберігати всередині рідної файлової системи Linux (наприклад, у домашньому каталозі, як-от ~/my-project), а не на змонтованих дисках Windows (наприклад, /mnt/c/). Так ви досягнете максимальної швидкості читання та запису.

Q: Чим відрізняється обробка імен файлів у Windows і Linux?

Файлові системи Linux чутливі до регістру (вони розглядають File.txt і file.txt як різні файли), тоді як NTFS у Windows за замовчуванням не чутлива до регістру. Запуск інструментів Linux у каталогах, розміщених у Windows, часто призводить до збоїв збірки через ці відмінності в поведінці.

By Mirko Peters · 2026-10-27

Дізнайтеся, чому доступ до файлів між ОС уповільнює WSL. Ознайомтеся з найкращими практиками зберігання на рідній файловій системі Linux та прискорення робочих процесів розробки.

Automatically translated with AI from the original post. Read the English original

Cover: Windows Subsystem for Linux (WSL) - Simply Explained

Дізнайтеся, чому змішування файлових систем Windows і Linux у Підсистемі Windows для Linux (WSL) створює серйозні вузькі місця в продуктивності. Ознайомтеся з ключовими правилами розміщення каталогів проєкту з правильного боку межі операційних систем, щоб значно прискорити ресурсомісткі завдання збірки, встановлення пакетів і операції з git.

Головне

Зберігання файлів проєкту Linux на дисках Windows (через /mnt/c/) суттєво знижує продуктивність через витрати на трансляцію при перетині межі.
Великі дерева файлів, як-от каталоги node_modules, найбільше страждають під час перетину межі ОС під час збірки та оновлень.
Офіційна рекомендація Microsoft: зберігайте файли в тій самій операційній системі, що й інструменти, якими ви їх редагуєте та компілюєте.
VS Code пропонує розширення Remote WSL, яке дозволяє безперешкодно редагувати файли, розміщені в Linux, з інтерфейсу Windows без втрати продуктивності.
Правила чутливості до регістру суттєво відрізняються у файловій системі Windows і Linux, тож правильне розміщення каталогів є необхідним, щоб уникнути несподіваних помилок.

Розуміння розподілу між файловими системами Windows і Linux

Однією з найпоширеніших пасток, у яку потрапляють розробники, переходячи на Підсистему Windows для Linux, є неправильне розміщення файлів. Windows і Linux керують своїм сховищем за принципово різними архітектурними парадигмами. Коли ви використовуєте WSL 2, ви працюєте з справжнім ядром Linux, що виконується всередині легкої віртуальної машини. Це означає, що ваш дистрибутив Linux має власну ізольовану рідну файлову систему, яка працює за стандартами POSIX.

Натомість стандартне середовище Windows спирається на NTFS і використовує літери дисків, як-от диск C:. Щоб подолати цю прогалину, WSL автоматично монтує диски Windows всередині середовища Linux у каталозі /mnt/ — наприклад, диск C з'являється як /mnt/c. Хоча це дозволяє читати й записувати кожен файл вашої хост-машини з терміналу Linux, це створює приховані й дуже дорогі витрати продуктивності, відомі як шлях трансляції через межу.

Чому доступ до файлів через межу так сповільнюється

Щоразу, коли інструмент Linux читає або записує файл, розташований на боці Windows, запит має пройти межу між легкою віртуальною машиною та хост-системою Windows. Для одного текстового файлу чи невеликого скрипта витрати на трансляцію непомітні. Однак сучасні робочі процеси розробки рідко обходяться одним файлом.

Розгляньмо, що відбувається, коли ви запускаєте команду на кшталт npm install або git clone у каталозі проєкту всередині /mnt/c/my-project. Ці операції генерують тисячі дрібних запитів на створення та зміну файлів у швидкій послідовності. Кожен із цих крихітних файлів сплачує вартість перетину межі. Сукупний ефект такий, що операції, які мали б тривати секунди, можуть тягнутися хвилинами, і багато розробників помилково вважають, що сам WSL за своєю природою повільний, тоді як винна лише неправильна організація каталогів.

Чутливість до регістру та конфлікти дозволів

Продуктивність — не єдина втрата під час переходу через межу між ОС. Правила файлової системи також конфліктують між собою так, що це ламає застосунки. Рідна файлова система Linux у корені суворо чутлива до регістру. Два файли з іменами Script.js і script.js сприймаються як повністю різні сутності. Windows NTFS за замовчуванням не чутлива до регістру.

Крім того, утиліти командного рядка Linux значною мірою покладаються на прапорці власності та дозволів, якими керують такі утиліти, як chmod і chown. Файлові системи Windows не відображають ці дозволи природним для інструментів Linux чином. Коли ви виконуєте код через межу між системами, символічні посилання можуть не розв'язуватися належним чином, а скрипти збірки можуть видавати незрозумілі помилки, бо не можуть застосувати дозволи до файлів, необхідні середовищу виконання.

Найкращі практики для швидких робочих процесів у WSL

Щоб уникнути цих пасток продуктивності та зберегти максимально плавний досвід розробки, дотримуйтеся двох базових правил. По-перше, завжди зберігайте проєкти Linux у рідній файловій системі Linux (десь у домашньому каталозі, наприклад ~/projects/), а проєкти, що працюють лише в Windows, залишайте на боці Windows.

По-друге, скористайтеся сучасними інструментами, щоб отримати зручний інтерфейс без втрати швидкості виконання. Відмовлятися від улюблених редакторів Windows не потрібно. Розширення Remote - WSL для Visual Studio Code дає змогу відкрити проєкт, який повністю зберігається у рідній файловій системі Linux, і при цьому користуватися звичним графічним інтерфейсом Windows. Редактор працює в Windows, а виконання коду, тестування та управління пакетами відбуваються на максимальній швидкості всередині середовища Linux.

Висновки та наступні кроки

Розуміння меж файлових систем — найважливіший крок до того, щоб WSL перестав бути складним експериментом і став вашим щоденним робочим інструментом. Тримаючи інструменти та файли на правильному боці поділу операційної системи, ви усуваєте затримки та уникаєте незрозумілих помилок дозволів.

Ширший погляд на те, як ця функція інтегрується в сучасні процеси розробки та хмарні робочі процеси, ви знайдете в повному випуску подкасту M365 FM Podcast. Перегляньте повну розмову, щоб дізнатися про короткі шляхи встановлення, порівняння версій і те, як WSL поєднує локальні машини з хмарною інфраструктурою Azure!

Поширені запитання

Де зберігати файли проєктів під час роботи з WSL?

Файли проєктів слід зберігати всередині рідної файлової системи Linux (наприклад, у домашньому каталозі, як-от ~/my-project), а не на змонтованих дисках Windows (наприклад, /mnt/c/), щоб забезпечити максимальну швидкість читання та запису.

Чому npm install повільно працює на диску Windows у WSL?

Менеджери пакетів на кшталт npm або pip під час встановлення створюють тисячі дрібних файлів. Коли ці файли записуються через межу між ОС на диск Windows NTFS, кожен окремий файл зазнає накладних витрат на перетворення, що призводить до значних проблем із продуктивністю.

Чи можна редагувати в Visual Studio Code файли, що зберігаються всередині файлової системи Linux?

Так. Встановивши розширення Remote - WSL для Visual Studio Code, ви зможете безпосередньо відкривати, редагувати та налагоджувати файли, розташовані всередині вашого дистрибутива Linux у WSL, користуючись стандартним інтерфейсом редактора Windows.

Чим відрізняється те, як Windows і Linux обробляють імена файлів?

Файлові системи Linux суворо чутливі до регістру (File.txt і file.txt вважаються різними файлами), тоді як Windows NTFS за замовчуванням не чутлива до регістру. Запуск інструментів Linux у каталогах, розміщених у Windows, часто призводить до помилок збірки через ці базові відмінності в поведінці.