Когда я только начал работать с WSL2 (Windows Subsystem for Linux), всё летало: спокойно клонировал репозитории, ставил зависимости, запускал приложения — настолько комфортно, что вскоре забыл, что это не полноценный Linux, а его “прослойка” в Windows.
Но со временем что-то пошло не так. Привычные команды стали думать по нескольку секунд. Установка пакетов затягивалась, файлы менялись с задержками, а dev-серверы реагировали как будто через ватный фильтр — но при этом никаких очевидных ошибок не возникало. Часто винили сам WSL2, но на деле проблема скрывалась гораздо глубже.
Всё решает то, где лежат ваши файлы
Невидимый тормоз: файловая система Windows подрезает скорость без предупреждения
Если ваш проект, например, лежит вот здесь:
Вы работаете не совсем в Linux — все ваши действия проходят через слой Windows, который постоянно посредничает.
Мелочь? На самом деле, это ключевой момент. В WSL2 крутится настоящее Linux-ядро внутри виртуальной машины. Там всё максимально быстро, предсказуемо, надёжно — именно так, как ждёшь от любой Linux-системы.
Но как только вы обращаетесь к папкам вроде /mnt/c, /mnt/d или любому другому «подключённому» диску Windows, каждый файловый запрос вынужден пересекать границу между мирами. Вот здесь и рождается тот самый “провал” производительности — медленно, без ошибок, что делает поиск причины особым квестом.
WSL — хорошая штука, но до идеала для Windows мне чего-то не хватает
Обычная виртуалка с Linux — не повод терпеть Copilot.
Почему всё так невыносимо тормозит
Чем больше файлов, тем сильнее “бьёт” по производительности
Современная разработка — это постоянная работа с файлами. Одна команда — и система создаёт, меняет или читает тысячи мелких файлов, всё должно происходить моментально и стабильно.
В “родном” Linux тут нет проблем — всё отлажено годами. А вот если проект лежит на диске Windows и работает через WSL2, каждый доступ к файлу превращается в вялотекущий танец двух операционок.
В результате вроде бы всё работает, но каждый шаг происходит с задержкой. Иногда замедление двукратное, иногда в десять раз — бывает и хуже. Сначала такие лаги трудно заметить: они тонко размазаны по множеству операций. Но со временем это становится очень заметно.
Хочется убедиться? Вот простой эксперимент: запустите git status или git checkout на большом репозитории, который лежит в /mnt/c, а потом проделайте то же самое, если проект лежит уже в домашней папке внутри Linux-файловой системы.
5 приёмов Git, которые кажутся настоящим читерством
Скрытые фишки Git экономят часы работы и снимают рутину.
Разница в скорости окажется огромной: Git будто специально любит “молотить” по файлам — сканирует директории, сверяет метаданные, ищет изменения. Если файловая система работает медленно — виноват не сам Git и не большой проект, а то, где всё это лежит.
Есть ещё один момент — сбои с отслеживанием изменений файлов. Вещи вроде webpack, Vite или nodemon работают только тогда, когда система вовремя сообщает о правках файлов. В Linux такие события “доходят” мгновенно.
На стыке с Windows уведомления часто запаздывают или теряются.
Вы наверняка столкнётесь с:
Это не баг в вашем любимом инструменте — так ведёт себя связка Windows+Linux, передающая уведомления о файлах друг другу. Стоит только переместить проект внутрь WSL2 — внезапно всё начинает работать идеально.
Crucial Pro Overclocking DDR5 RAM 32GB (2x16GB) 6000MHz CL36
Почему /mnt/c только кажется удобным решением
Привычное удобство оборачивается “налогом” на скорость
Я отлично понимаю, почему большинство выкладывает проекты прямо на диск Windows: редактор там же, файлы под рукой — проще всего зайти к ним через /mnt/c прямо из WSL2.
Кажется, будто всё живёт на одной общей файловой системе — и для Windows, и для Linux. На самом деле это не так — между ними “мостик”, который берёт свой процент с каждого обращения.
Если вам нужно только время от времени открыть пару файлов — можно так оставить. Но для серьёзной работы, где файлы постоянно меняются, такой путь становится тупиковым.
Стоит только перенести проект в настоящую Linux-файловую систему внутри WSL2 — путь будет примерно такой:
Теперь у вас “чистый” Linux: никаких невидимых переводов и задержек. Установки зависимостей — сразу; запуск серверов — молниеносный.
А если надо открыть файлы из самой Windows?
Популярные редакторы давно умеют работать с Linux-проектами напрямую
Тут у многих вопрос: если проект хранится внутри WSL2, как он попадёт в привычный Windows-редактор?
На самом деле всё давно просто. Например, в VS Code есть модуль Remote WSL: вы открываете папку из Linux, редактор продолжает работать на Windows, а все файлы живут в WSL2 — оба мира вместе, но без лагов.
Вот так и выглядит современная разработка: никаких “прослоек”, никаких лагов. Если что-то экзотичное — к WSL2 легко подключиться через особые пути:
Но для постоянной разработки “удалённый” доступ — верное и самое удобное решение.
Кому всё же имеет смысл работать через /mnt/c
Иногда файловая система Windows всё-таки выигрывает
Если быть честным, и файловая система Windows в паре с WSL2 иногда весьма полезна. Например, удобно тянуть документы, медиа, быстро запускать небольшие скрипты, шарить файлы между двумя мирами или, например, пользоваться утилитами, которых нет на Linux. Но для разработки, где весь день ставишь зависимости, пересобираешь проект и меняешь кучу файлов — это не вариант. Относитесь к WSL2 как к полноценной системе Linux, органично интегрированной в ваш компьютер, а не как к “слою поверх Windows”.
3 необычные утилиты Linux, которые стоит запустить через WSL на Windows 10
Пробовали ставить Linux-программы на “десятку”? Вот какие точно понравятся.
Если смотреть на всё под этим углом, выбор файловой системы предельно прост. А разработка через “сетку” с задержками — это добровольное издевательство. Для WSL2 “своим” всегда остаётся Linux-диск, а Windows — просто сосед, вроде “удалённой папки”.
Решение — реально за пару минут!
Просто перенесите проект внутрь Linux, либо скачайте новый клон
Всё решается очень легко: просто переместите папку с проектом внутрь WSL2.
Или склонируйте репозиторий заново, но уже изнутри Linux.
В редакторе укажите новый путь до своего проекта.
Не конфиг, а местоположение — главное для скорости!
WSL2 работает быстрее всего, когда ваш проект лежит прямо на его родной файловой системе. Как только файлы оказываются в “своём” окружении, все тормоза исчезают. Windows остаётся только удобной оболочкой — вся работа происходит там, где её и ждут инструменты Linux.
Самое удивительное — насколько резко увеличивается скорость всего одним простым действием. Обычное “перетащить проект” даёт больше, чем тонкая настройка WSL2 и пляски с бубном. Когда вы поймёте эту разницу, все загадочные лаги и “мистические баги” закономерно уходят сами собой — потому что теперь вы работаете не на стыке двух миров, а там, где всё уже оптимально по умолчанию.
Если вам понравилась эта статья, подпишитесь, чтобы не пропустить еще много полезных статей!
Премиум подписка - это доступ к эксклюзивным материалам, чтение канала без рекламы, возможность предлагать темы для статей и даже заказывать индивидуальные обзоры/исследования по своим запросам!Подробнее о том, какие преимущества вы получите с премиум подпиской, можно узнать здесь
Также подписывайтесь на нас в:
- Telegram: https://t.me/gergenshin
- Youtube: https://www.youtube.com/@gergenshin
- Яндекс Дзен: https://dzen.ru/gergen
- Официальный сайт: https://www-genshin.ru