Почему npm install медленно работает на диске Windows в WSL?

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

Можно ли использовать Visual Studio Code для редактирования файлов в файловой системе Linux?

Да. Установив расширение Remote - WSL для Visual Studio Code, вы сможете напрямую открывать, редактировать и отлаживать файлы внутри дистрибутива Linux в WSL, работая при этом в привычном интерфейсе редактора Windows.

Производительность файловой системы WSL: почему доступ через границу ОС замедляет ваш код

Q: Где хранить файлы проекта при использовании WSL?

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

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, часто приводит к сбоям сборки из-за этих различий в поведении.