n1ro°
RU

Компьютеры · Инструкция

Windows Dev Drive: как создать и настроить

Windows Dev Drive — специализированный том для разработчиков, а не универсальный «ускоритель SSD».

Редакция N1RO · Проверено

Короткий ответ

Как создать Dev Drive в Windows 11, выбрать VHDX или отдельный том, учесть минимум 50 ГБ и понять, какие репозитории и кэши стоит переносить.

Когда Dev Drive имеет смысл

Microsoft рекомендует размещать на Dev Drive исходный код, локальные Git-репозитории, кэши менеджеров пакетов и промежуточные результаты сборки. Именно такие каталоги часто содержат тысячи мелких файлов и активно читаются и записываются инструментами разработки. Отдельный том также помогает логически отделить рабочие данные от системы. Но это не обязательное требование для Visual Studio, VS Code, Git, npm или Python: обычный NTFS-диск продолжает работать. Dev Drive стоит создавать, когда вы понимаете, какие каталоги переместите и зачем, а не ради одной галочки в Settings.

Важно: Не переносите на Dev Drive единственную копию исходников без резервного копирования. Оптимизированный том не заменяет Git remote и бэкап.

Требования перед созданием

  • Windows 11 с поддержкой Dev Drive; Microsoft указывает минимум сборку 22621.2338;
  • права администратора для создания или изменения тома;
  • минимум 50 ГБ свободного пространства под новый Dev Drive;
  • достаточно оперативной памяти: Microsoft рекомендует 16 ГБ, минимально указывает 8 ГБ;
  • понимание, будет ли это VHD/VHDX-файл или отдельный раздел физического диска;
  • план резервного копирования репозиториев и настроек, которые будут храниться на томе.

Совет: Если не хотите сразу менять разделы физического диска, VHDX удобен для пробного Dev Drive: его проще удалить после теста.

Как создать Dev Drive через Settings

  1. Откройте «Параметры» → «Система» → «Хранилище» → дополнительные параметры хранилища → «Диски и тома».
  2. Выберите создание Dev Drive. Windows предложит создать новый VHD/VHDX или использовать свободное нераспределённое пространство после изменения размеров томов.
  3. Для VHDX задайте расположение файла, имя и размер. Для физического диска убедитесь, что уменьшение существующего раздела не затронет нужные данные.
  4. Создайте том требуемого размера и назначьте букву. Dev Drive использует ReFS и специальную маркировку системы.
  5. После появления диска создайте на нём отдельные каталоги, например `repos`, `package-cache` и `build`, вместо хаотичного переноса всего профиля пользователя.
  6. Перемещайте по одному типу нагрузки и проверяйте инструменты: Git remote, IDE, пути к кэшу и скрипты CI должны ссылаться на новое место.

Совет: Переносите сначала один репозиторий или один кэш. Так проще измерить эффект и быстро откатить путь, если инструмент оказался несовместим.

Что хранить на Dev Drive, а что оставить где было

  • Git-репозитории. хороший кандидат; особенно крупные деревья с множеством файлов
  • кэш npm/pip/NuGet и похожих инструментов. хороший кандидат, если инструмент позволяет явно изменить путь
  • build/output временных сборок. подходит, если результат можно восстановить повторной сборкой
  • Windows и Program Files. не переносить; Dev Drive не является заменой системного тома C:
  • единственная копия личных документов. нет преимущества, а резервное копирование всё равно обязательно

Предупреждение: Смысл Dev Drive — в конкретных dev-нагрузках. Чем меньше случайных пользовательских данных вы смешиваете с ними, тем проще обслуживать том.

Почему нельзя просто преобразовать существующий C: или NTFS-том

Dev Drive основан на ReFS и создаётся как отдельный том с соответствующей конфигурацией. Microsoft прямо отмечает, что существующий том нельзя преобразовать в Dev Drive «на месте», а системный C: не может быть Dev Drive. Если на физическом диске уже всё пространство занято, типичный путь — уменьшить существующий том и создать новый в высвободившейся области либо использовать VHD/VHDX. Любое изменение разделов требует резервной копии важных данных: ошибка питания, неверно выбранный диск или недостаток свободного места превращают простую настройку в риск потери данных.

Defender Performance Mode и доверие к Dev Drive

Одна из причин производительности Dev Drive связана с тем, как Microsoft Defender может работать с доверенным dev-томом в performance mode. Это не означает, что диск «не проверяется вообще» или что на него безопасно складывать неизвестные исполняемые файлы. Настройка доверия должна соответствовать рабочей среде и политике безопасности организации. Если вы скачиваете случайные репозитории или запускаете непроверенные скрипты, происхождение кода остаётся главным риском. На корпоративном ПК параметры Defender могут централизованно управляться, и локальный пользователь не должен обходить установленные ограничения ради потенциального ускорения сборки.

Как понять, что Dev Drive дал пользу

Сравнивайте измеримые операции: `git status` на большом дереве, установку зависимостей из локального кэша, полную и инкрементальную сборку. Делайте несколько запусков, потому что файловый и пакетный кэш сильно влияют на первый результат. Если проект маленький, а сборка упирается в компилятор или CPU, разница файловой системы может потеряться в шуме. Если ускорения нет, это нормально: Dev Drive оптимизирует определённый класс операций, а не каждую команду. Важнее, чтобы новая структура путей не усложнила резервное копирование, скрипты и совместную работу команды.

Почему Dev Drive лучше тестировать на одном проекте

Dev Drive предназначен для рабочих нагрузок разработки, а не для ускорения всего компьютера. Поэтому переносить сразу все репозитории, SDK и кэши неудобно: если конкретный инструмент не поддерживает новый путь или вы не увидите пользы, откат станет длиннее. Начните с одного проекта, где много мелких файлов, частые операции Git, установка пакетов или интенсивная сборка. Зафиксируйте привычное время клонирования, восстановления зависимостей и полной сборки, затем повторите те же операции на Dev Drive. Не сравнивайте разные версии зависимостей или прогретый кэш с чистым — такой тест ничего не говорит о диске. Если выигрыш есть и инструменты работают корректно, переносите следующие каталоги постепенно. Если разницы нет, это не ошибка конфигурации: нагрузка могла упираться в процессор, сеть или другой этап, а не в файловую систему.

Что важно знать о размере, VHDX и существующих томах

Microsoft требует для Dev Drive минимум 50 ГБ и указывает Windows 11 build 22621.2338 или новее. Существующий обычный том нельзя просто переключить в Dev Drive: обозначение задаётся при создании и форматировании. Если свободного места мало, можно уменьшить другой том и создать новый в нераспределённой области; для эксперимента удобен VHDX, который Microsoft рекомендует среди форматов виртуального диска. Динамически расширяемый VHDX экономит место в начале, но его файл всё равно должен находиться на носителе с достаточным запасом. Не храните на таком тестовом диске единственную копию исходников. Git remote, резервная копия и воспроизводимая конфигурация сборки остаются обязательными: Dev Drive оптимизирует хранение для dev-сценариев, но не решает задачу сохранности данных. После успешного теста зафиксируйте новые пути в настройках IDE, пакетных менеджеров и скриптов сборки. Иначе часть инструментов останется на старом томе, и измерение производительности будет смешивать разные хранилища, что затруднит диагностику и последующий перенос проекта.

Практический контроль результата

Отдельный Dev Drive не отменяет обычную гигиену диска. Оставляйте свободное место, следите за резервными копиями и не используйте его как временную свалку, потому что переполненный том ухудшает любые файловые операции. Для команды документируйте новые пути к кэшам и репозиториям, иначе локальная оптимизация одного разработчика превращается в непереносимые скрипты. Хороший результат — когда проект можно клонировать заново, зависимости восстановить, а build output удалить без потери уникальных данных; тогда Dev Drive действительно содержит воспроизводимую рабочую нагрузку.

Что учитывать

Dev Drive основан на ReFS и создаётся как отдельный том с соответствующей конфигурацией. Microsoft прямо отмечает, что существующий том нельзя преобразовать в Dev Drive «на месте», а системный C: не может быть Dev Drive. Если на физическом диске уже всё пространство занято, типичный путь — уменьшить существующий том и создать новый в высвободившейся области либо использовать VHD/VHDX. Любое изменение разделов требует резервной копии важных данных: ошибка питания, неверно выбранный диск или…

Источники и проверка

Фактическая часть сверена по первичным источникам (в т.ч. Set up a Dev Drive on Windows 11). Пример и формулировки — редакция N1RO на 2026-09-20.