Dev Drive у Windows 11: прискорення збірок (чесно)

Що таке Dev Drive насправді (і чого він не робить)

Dev Drive — це функція Windows, яка створює том, орієнтований на розробників, зазвичай форматований ReFS (Resilient File System) і налаштований так, щоб зменшити «смерть від тисячі файлових операцій» у дереві збірки. Воно супроводжується змінами в поведінці Microsoft Defender, спрямованими на те, щоб сканування було менш руйнівним для директорій з високою інтенсивністю змін.

Це не магія. Він не «зробить ваш CPU швидшим». Він не виправить проєкт із патологічним графом збірки. Він не перетворить жорсткий диск на SSD. Він в основному атакує одну конкретну біль: велику кількість дрібних файлових операцій, де антивірус і метадані файлової системи стають домінуючими витратами.

Dev Drive має обмеження та компроміси. ReFS поводиться інакше ніж NTFS. Деякі інструменти розраховують на хитрощі NTFS. Деякі корпоративні політики очікують «тільки C:\». Та й резервні копії можуть поводитись дивно, якщо в вашій організації вважають, що «машини розробників не потребують їх» (сміливий підхід).

Якщо ви в основному будуєте контейнери у WSL2 з примонтованими шляхами у Windows, Dev Drive все ще може мати значення — бо проблема часто у межі файлових систем Windows, а не всередині Linux. Але якщо вузьке місце — це CPU‑інтенсивна компіляція або пропуски в віддаленому кебі, Dev Drive ввічливо нічого не робитиме.

Чому збірки повільні на Windows: реальні вузькі місця

Проблеми з продуктивністю збірок зазвичай бувають трьох типів:

1) CPU‑залежність: ви справді компілюєте

Коли ви компілюєте великі модулі, виконуєте JIT або робите важку оптимізацію, диск — лише допоміжний актор. Dev Drive тут мало чим допоможе. Ваші покращення приходять від паралелізму, PCH, інкрементальних збірок, розподіленої компіляції та уникнення повного пересобору при зміні коментаря.

2) I/O‑залежність на дрібних файлах: податок «node_modules»

Це класика. Відновлення пакетів, клонування Git, індексація сервером мови та системи збірки, що обходять величезні дерева. Диск не «повільний» пропускною здатністю; він повільний у сенсі затримок та метаданих: відкриття, закриття, stat і сканування гори дрібних файлів.

Антивірус ускладнює це, бо кожне створення/відкриття може викликати гачки сканування та драйвери‑фільтри. Це навантаження не є постійним; воно зростає, коли збірка генерує нові бінарники та проміжні артефакти. Тож збірки відчуваються «випадково повільними» — найгірший вид повільності.

3) Патологічна поведінка інструментів: мовчазний вбивця

Деякі інструменти повторно сканують дерево. Деякі генерують величезну кількість проміжних файлів. Деякі записують логи синхронно. Деякі використовують спостерігачі файлів, що при відсутності подій переходять у опитування і карають ваше сховище. Ви можете кинути в це ReFS і все одно програти.

Dev Drive націлений саме на категорію 2: дерева розробки, які фактично є тестом метаданих. Якщо це ваш випадок — варто серйозно розглянути цю опцію.

Цитата варта запам’ятовування (перефразована думка): Gene Kim часто підкреслює, що швидкі зворотні зв’язки — основа ефективної доставки та надійності. Час збірки — це проблема надійності.

Жарт №1: Якщо ваша збірка потребує перерви на каву, вона не «ретельна», швидше за все чекає на антивірус.

Цікаві факти та історичний контекст

1. ReFS з’явився у Windows Server 2012 як файлову систему наступного покоління, орієнтовану на стійкість та цілісність, а не на сумісність зі старими сценаріями.
2. NTFS походить з початку 1990‑х. Він перевірений у бою, але несе десятиліття сумісницьких поведінок, не оптимізованих для сучасних робочих навантажень розробників.
3. Windows Defender використовує драйвери‑фільтри файлової системи для інспекції активностей. Це потужно — і водночас головне джерело накладних витрат на файл під час збірок.
4. Робочі навантаження розробників змінилися: «репозиторій» часто означає сотні тисяч файлів після додавання залежностей та згенерованих артефактів.
5. Робочі процеси на основі VHD/VHDX у операційників давно знайомі; ми ізолюємо навантаження віртуальними дисками вже роками, бо їх легко переміщувати, знімати снапшоти і повністю скидати.
6. ReFS історично був «серверною штукою», але Dev Drive приносить його на клієнтські машини розробників у цілеспрямований спосіб, а не як універсальну заміну.
7. Раніше прискорення збірок означало швидші диски; тепер часто воно означає зменшення «роботи на файл» через кешування, розумніші сканування та уникнення зайвих доторків до файлової системи.
8. Функції перевірки цілісності файлів мають витрати. Контрольні суми і валідація покращують надійність, але додають CPU і I/O накладні витрати, якщо не налаштовані під конкретне навантаження.
9. Жорсткість політик безпеки Windows зростала з часом, і це добре — поки ваша директорія збірки не виглядає як поведінка шкідливого ПЗ (швидке створення файлів, компіляція, виконання).

Під капотом: ReFS, фільтри та чому Defender важливий

ReFS проти NTFS для дерев розробки

ReFS (Resilient File System) спроєктований з урахуванням сучасних припущень щодо зберігання: великі томи, функції цілісності та обробка метаданих, яка може бути дружнішою при великій паралельній файловій активності. Для збірок практичний наслідок часто: менше «дивних затримок», коли багато процесів одночасно створюють і запитують файли.

Але ReFS не є повноправною заміною всіх функцій NTFS. Деякі специфічні поведінки NTFS відсутні або працюють інакше. Якщо ваші інструменти покладаються на старі припущення (компресія NTFS, EFS або певні випадки з reparse‑point), треба протестувати. Не впроваджуйте це як політику одночасно для всіх.

Defender: не лиходій, але він у «гарячому шляху»

Чесно: Defender виконує свою роботу. Збірки виглядають підозріло. Вони створюють виконувані файли, пишуть у тимчасові директорії, завантажують пакети та запускають скрипти. Продукт безпеки, який ігнорував би це, був би… творчо недбалим.

Пропозиція Dev Drive не в «вимкнути безпеку». Вона в «застосувати продуктивніший підхід до сканування для довірених директорій розробки», зменшуючи постійний податок сканування при кожному відкритті файлу. Це різниця між прагматичним налаштуванням і інцидентом безпеки, що чекає на свою можливість.

Модель I/O, на яку орієнтується Dev Drive

• висока частота створення/відкриття/закриття файлів
• багато одночасних читань дрібних файлів
• швидка зміна в проміжних директоріях (obj/bin, bazel-out, target, dist, build, .gradle тощо)
• повторювані локальні «відомі» шляхи, де сканування кожного доступу менше цінне, ніж сканування на межах

Якщо ваша збірка робить тривалі послідовні великі читання/записи (наприклад, відеоактиви, монолітні архіви), Dev Drive може бути нейтральним. Ваше обмеження — швидкість SSD, контролер або термальне обмеження, а не шлях метаданих файлової системи.

Варіанти налаштування: розділ, VHDX або «будь ласка, не робіть так»

Варіант A: Виділений розділ (найкраще для щоденного серйозного використання)

Коли у вас є вільне місце, виділений том — просте рішення. Передбачувана літера диска, стабільна продуктивність, менше шарів. Якщо у вас один швидкий NVMe і ви постійно збираєте, зазвичай це найчистіший варіант.

Використовуйте це, коли: ви стабільно працюєте на одній машині, маєте права адміністратора і хочете найменше несподіванок.

Варіант B: VHDX Dev Drive (найкраще для ізоляції та портативності)

Dev Drive на основі VHDX — солідний компроміс: можна виділяти динамічно, розміщувати на швидкому диску і видаляти, якщо він пошкодиться або розростеться. Також полегшує «окремі середовища розробки»: один VHDX на клієнта або на велику гілку.

Використовуйте це, коли: хочете зберегти чисту базову ОС, часто відновлюєте машини або підтримуєте кілька несумісних стеків інструментів.

Варіант C: Розміщення всього життя на Dev Drive (не робіть)

Dev Drive призначений для вихідного коду, залежностей і артефактів збірки. Не для сімейних фото. Не для менеджера паролів. Не для папки «Завантаження», де осідають випадкові виконувані файли. Зменшіть радіус ураження. Позиція безпеки базується на межах довіри, тож вашу директорію розробки слід розглядати як спеціальну зону, а не як усе місто.

Жарт №2: Якщо ви зберігаєте весь домашній каталог на Dev Drive, вітаю — ви винайшли «продакшн» з менше резервними копіями.

Практичні завдання: команди, виводи та рішення

Нижче — реальні завдання, які я виконую на Windows 11 машині розробника, коли хтось каже «Dev Drive не допоміг» або «Dev Drive вирішив все». Ми ставимо обидва твердження під сумнів.

Важливо: Команди наведені PowerShell. Фрагменти виводів — прикладні. Ваші значення відрізнятимуться. Суть — що ви дізнаєтесь і яке рішення приймете.

Завдання 1: Підтвердити, що збірка Windows підтримує функції Dev Drive

cr0x@server:~$ powershell -NoProfile -Command "Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber"
WindowsProductName WindowsVersion OsBuildNumber
----------------- -------------- -------------
Windows 11 Pro     23H2          22631

Що це означає: Потрібна сучасна версія Windows 11, де Dev Drive доступний і стабільний. На старішій збірці поведінка і варіанти UI можуть відрізнятись.

Рішення: Якщо ОС застаріла — оновіть спочатку. Не тестуйте функцію, яку не можете повністю використати.

Завдання 2: Перелік томів і типів файлових систем (знайдіть ReFS чи NTFS)

cr0x@server:~$ powershell -NoProfile -Command "Get-Volume | Sort-Object DriveLetter | Format-Table DriveLetter, FileSystem, FileSystemLabel, SizeRemaining, Size -Auto"
DriveLetter FileSystem FileSystemLabel SizeRemaining      Size
----------- ---------- -------------- -------------      ----
C           NTFS       Windows        122.4 GB       476.8 GB
D           ReFS       DevDrive       311.2 GB       476.8 GB

Що це означає: У вас є том ReFS з міткою DevDrive. Добре. Якщо це NTFS — ви не тестуєте головний файловий аспект Dev Drive.

Рішення: Якщо ваш «Dev Drive» насправді NTFS — зупиніться. Виправте це перед тим, як звинувачувати функцію.

Завдання 3: Перевірити, чи диск дійсно SSD/NVMe

cr0x@server:~$ powershell -NoProfile -Command "Get-PhysicalDisk | Format-Table FriendlyName, MediaType, BusType, Size -Auto"
FriendlyName          MediaType BusType Size
------------          --------- ------- ----
NVMe Samsung SSD 980  SSD       NVMe    1 TB

Що це означає: Якщо MediaType — HDD або BusType — USB, ви оптимізуєте не той шар. Dev Drive не вирішує проблем з обертальною латентністю або повільними зовнішніми корпусами.

Рішення: Якщо це не NVMe/SSD — поміняйте розміщення обладнання перед налаштуванням файлової системи.

Завдання 4: Перевірити вирівнювання розділу (неправильне вирівнювання шкодить випадковому I/O)

cr0x@server:~$ powershell -NoProfile -Command "Get-Partition -DriveLetter D | Select-Object DriveLetter, Offset, Size"
DriveLetter Offset   Size
----------- ------   ----
D           1048576  476.8 GB

Що це означає: Зміщення 1 048 576 байт (1 MiB) — сучасне «хороше» вирівнювання. Дивні зміщення можуть спричиняти додаткові читання/записи.

Рішення: Якщо вирівнювання дивне (не близько до 1 MiB) — пересоздайте розділ. Не сперечайтесь із фізикою.

Завдання 5: Подивитись, чи Defender у гарячому шляху для вашого дерева збірки

cr0x@server:~$ powershell -NoProfile -Command "Get-MpPreference | Select-Object -ExpandProperty ExclusionPath"
C:\Windows\Temp

Що це означає: Мінімальні виключення. Це нормально в жорстко контрольованих середовищах. Але якщо ваша директорія розробки не має спеціального ставлення, Defender може сканувати агресивно.

Рішення: Якщо політика дозволяє, налаштуйте Dev Drive правильно, а не розкидайте широкі виключення скрізь.

Завдання 6: Підтвердити стан реального часу захисту Defender (не припускайте)

cr0x@server:~$ powershell -NoProfile -Command "Get-MpComputerStatus | Select-Object RealTimeProtectionEnabled, BehaviorMonitorEnabled, AntivirusEnabled"
RealTimeProtectionEnabled BehaviorMonitorEnabled AntivirusEnabled
------------------------ ---------------------- ---------------
True                     True                   True

Що це означає: Defender активний. Добре. Тепер треба ставитись до налаштування продуктивності як до «зробити сканування розумнішим», а не «вимкнути його».

Рішення: Якщо ви думали, що Defender вимкнений, а він увімкнений — ваші передумови для бенчмарку вже зламані.

Завдання 7: Виміряти вплив Defender контролюваним тестом обходу файлів

cr0x@server:~$ powershell -NoProfile -Command "Measure-Command { Get-ChildItem -Recurse -File D:\repo | Out-Null } | Select-Object TotalSeconds"
TotalSeconds
------------
7.814

Що це означає: Це грубий інструмент, але корисний. Обхід директорії — велика частина багатьох збірок (глобінг, сканування залежностей, індексація).

Рішення: Виконайте той самий тест на NTFS з тим самим репозиторієм. Якщо ReFS + Dev Drive значно швидше — ви в цільовій зоні.

Завдання 8: Перевірити індексацію Windows Search на томі розробки

cr0x@server:~$ powershell -NoProfile -Command "Get-Service WSearch | Select-Object Status, StartType, Name"
Status StartType Name
------ --------- ----
Running Automatic WSearch

Що це означає: Індексація може додавати фонові I/O та відкриття файлів. Не завжди критично, але іноді конфліктує з вашим навантаженням.

Рішення: Якщо збірки нестабільні під час індексації, зменшіть список індексованих локацій або виключіть том розробки з індексації (за наявності дозволу політики).

Завдання 9: Перевірити черги диска та затримки під час фактичної збірки

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\PhysicalDisk(_Total)\Avg. Disk sec/Read','\PhysicalDisk(_Total)\Avg. Disk sec/Write','\PhysicalDisk(_Total)\Current Disk Queue Length' -SampleInterval 1 -MaxSamples 3"
Timestamp                 CounterSamples
---------                 --------------
2/5/2026 10:14:01 AM      \\...\Avg. Disk sec/Read : 0.004
                           \\...\Avg. Disk sec/Write: 0.012
                           \\...\Current Disk Queue Length: 1
2/5/2026 10:14:02 AM      \\...\Avg. Disk sec/Read : 0.021
                           \\...\Avg. Disk sec/Write: 0.034
                           \\...\Current Disk Queue Length: 9
2/5/2026 10:14:03 AM      \\...\Avg. Disk sec/Read : 0.018
                           \\...\Avg. Disk sec/Write: 0.028
                           \\...\Current Disk Queue Length: 7

Що це означає: Затримки в одиницях мілісекунд — нормальні. Коли бачите десятки мілісекунд і високі довжини черг, ви обмежені підсистемою зберігання (або відбувається тротлінг).

Рішення: Якщо затримки зростають під час відновлення залежностей та генерації файлів, Dev Drive релевантний. Якщо затримки сталі, а CPU завантажений — дивіться інше.

Завдання 10: Визначити процеси, що сильно б’ють по диску

cr0x@server:~$ powershell -NoProfile -Command "Get-Process | Sort-Object IOReadBytes -Descending | Select-Object -First 5 Name, Id, IOReadBytes, IOWriteBytes"
Name           Id IOReadBytes IOWriteBytes
----           -- ----------- ------------
MsMpEng      4212  987654321    123456789
node         15840  654321098     98765432
cl           17400  612345678    212345678
dotnet       18888  512345678    112345678
git          19544  212345678     12345678

Що це означає: Якщо MsMpEng (Defender) на верхівці під час збірок — ви знайшли головного підозрюваного. Якщо це ваш компілятор і лінкер — можливо, ви просто багато збираєте.

Рішення: Високі IO у MsMpEng свідчать, що потрібно правильно налаштувати Dev Drive і/або межі сканування.

Завдання 11: Перевірити, що репозиторій знаходиться на потрібному томі

cr0x@server:~$ powershell -NoProfile -Command "Resolve-Path D:\repo | Select-Object Path"
Path
----
D:\repo

Що це означає: Ви здивуєтесь, як часто люди тестують «Dev Drive», а їхній репо насправді лежить на C:\ через симлінк, налаштування IDE або звичку м’язів.

Рішення: Якщо репозиторій не на Dev Drive — перемістіть його. Потім повторіть тест.

Завдання 12: Виявити reparse‑point і проблемні симлінки в репо

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem D:\repo -Force -Attributes ReparsePoint -Recurse -ErrorAction SilentlyContinue | Select-Object -First 5 FullName, LinkType"
FullName                               LinkType
--------                               --------
D:\repo\node_modules\.bin\eslint.cmd   Junction
D:\repo\packages\shared\dist           SymbolicLink

Що це означає: Деякі інструменти та сканери поводяться погано з junction/symlink, викликаючи повторні сканування або навіть цикли.

Рішення: Якщо бачите багато reparse‑point, перевірте сумісність ваших інструментів і правил сканування. Розгляньте спрощення структури, якщо вона патологічна.

Завдання 13: Перевірити вільне місце і ризик фрагментації (так, навіть на SSD)

cr0x@server:~$ powershell -NoProfile -Command "Get-Volume -DriveLetter D | Select-Object DriveLetter, SizeRemaining, Size, HealthStatus"
DriveLetter SizeRemaining      Size HealthStatus
----------- -------------      ---- ------------
D           311.2 GB       476.8 GB Healthy

Що це означає: Dev‑наванттаження швидко розростаються. Низьке вільне місце збільшує write amplification і може викликати неприємні поведінки SSD.

Рішення: Якщо вільного місця менше ~15–20%, розширте том або почистіть кеші збірки. Не «оптимізуйте» майже повний диск.

Завдання 14: Шукати тепловий тротлінг та налаштування живлення

cr0x@server:~$ powershell -NoProfile -Command "powercfg /getactivescheme"
Power Scheme GUID: 381b4222-f694-41f0-9685-ff5bb260df2e  (Balanced)

Що це означає: Режим «Balanced» зазвичай підходить, але ноутбуки під важким навантаженням можуть знижувати частоти CPU або тротлити сховище через нагрів.

Рішення: Якщо продуктивність падає через кілька хвилин, спробуйте «Best performance» і слідкуйте за термальними показниками. Dev Drive не виправить, якщо ноутбук «пече» сам себе.

Завдання 15: Перевірити, що збірка справді інкрементальна

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem D:\repo\build -Recurse -File | Measure-Object | Select-Object Count"
Count
-----
182344

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

Рішення: Якщо кількість артефактів розростається — додайте політики очищення і впевніться, що ваш інструмент збірки не вимикає інкрементальність помилково.

Швидкий план діагностики (знайти вузьке місце за 15 хвилин)

Це послідовність «перестаньте сперечатися і виміряйте». Робіть у порядку. Кожен крок або підтвердить, що Dev Drive — правильний важіль, або скаже, щоб ви припинили витрачати час.

Перший: вирішіть, чи ви I/O‑обмежені або CPU‑обмежені

• Перевірте насичення CPU: якщо всі ядра завантажені, а затримка диска низька, Dev Drive навряд чи врятує ситуацію.
• Перевірте затримки диска і довжину черги під час повільного кроку: якщо затримки піднімаються й черга зростає — ви I/O‑обмежені.

Другий: визначте, чи сканування безпеки — це податок

• Якщо MsMpEng серед топ‑процесів I/O під час збірок — Defender суттєво впливає.
• Якщо I/O Defender низький — зосередьтесь на інструментах (резолвер залежностей, лінкер, спостерігачі файлів) або на обладнанні зберігання.

Третій: доведіть, що шар зберігання — це те, що ви думаєте

• Підтвердьте, що репо на томі Dev Drive.
• Підтвердьте, що цей том на SSD/NVMe (а не «швидкому» зовнішньому, який насправді є вузьким місцем).
• Підтвердьте вільне місце та відсутність очевидних конфігураційних проблем (індексація, агенти резервного копіювання, синхронізатори).

Четвертий: використовуйте A/B‑тест, а не відчуття

Візьміть один репрезентативний сценарій: чисте клонування + відновлення пакетів + збірка. Запустіть його на NTFS і на Dev Drive, на тій же машині, на тому ж коміті, у тому ж режимі живлення. Якщо різниця в межах шуму — Dev Drive не ваш ліміт.

Поширені помилки (симптом → причина → виправлення)

1) «Dev Drive нічого не дав»

Симптом: Часи збірки не змінилися після переміщення репо.

Корінь проблеми: Повільна фаза CPU‑залежна (компіляція/лінкер) або мережна (завантаження пакетів).

Виправлення: Профілюйте фази збірки. Якщо CPU‑залежне — покращуйте інкрементальність, паралелізм і кешування. Якщо мережне — використовуйте локальні кеші, дзеркала або lockfile. Dev Drive не прискорює мережу.

2) «Dev Drive повільніший за C:\»

Симптом: Файлові операції відчуваються повільними; індексація IDE повільніша.

Корінь проблеми: Dev Drive розміщений на повільнішому носії (другорядний SSD, зовнішній корпус) або всередині VHDX, що бере ресурси на завантаженому диску.

Виправлення: Помістіть Dev Drive на найшвидший локальний NVMe. Якщо використовуєте VHDX — переконайтеся, що хост‑диск має запас та не ділиться з інтенсивними іншими навантаженнями (синхронізатори, образи VM, ігри — так, ігри теж генерують I/O).

3) «Мій стек зламався після переходу на Dev Drive»

Симптом: Git‑хуки падають, кроки збірки помиляться, дивні проблеми з дозволами.

Корінь проблеми: Інструмент покладався на специфічну поведінку NTFS, припущення про шляхи або корпоративну політику, жорстко закодовану на C:\.

Виправлення: Перевірте сумісність інструментів з ReFS. Там, де потрібно, тримайте конкретні директорії на NTFS (наприклад, для застарілих інструментів) і помістіть «галасливі» артефакти на Dev Drive. Розділяйте навантаження замість примусу до єдності.

4) «Відновлення пакетів усе ще повільне»

Симптом: npm/pnpm/yarn, NuGet, Maven/Gradle відновлення займають вічність.

Корінь проблеми: Мережева латентність, TLS‑інспекція або корпоративний проксі, що проводить глибоке сканування. Локальна файлова система тут не головна причина.

Виправлення: Виміряйте час завантаження окремо від часу розпакування. Використовуйте локальні кеші, де дозволено. Якщо TLS‑інспекція — вузьке місце, підніміть питання з доказами; не просто скаржтесь.

5) «Диск швидкий, але збірки мають нестабільність»

Симптом: Деякі прогони швидкі, деякі повільні, без змін у коді.

Корінь проблеми: Фонові завдання: індексація, синхронізатори, агенти резервного копіювання, повні сканування Defender або Windows Update.

Виправлення: Перевірте процеси‑винуватці під час повільних прогонів. Плануйте важку фонову роботу поза робочими годинами або виключіть Dev Drive з індексації, якщо політика дозволяє.

6) «WSL‑збірки повільні, хоча Linux місцево швидкий»

Симптом: Збірки у WSL2 повільні, коли репо під /mnt/c або іншим шляхом Windows.

Корінь проблеми: Перетин файлових систем між ОС. Багато викликів метаданих перетинає межу.

Виправлення: Тримайте репо всередині файлової системи WSL для нативних Linux‑збірок або використайте Dev Drive і протестуйте, чи зменшується штраф межі. Не припускайте — вимірюйте.

7) «Dev Drive миттєво заповнився»

Симптом: Ви втрачаєте десятки ГБ за тиждень.

Корінь проблеми: Кеші збірки та директорії артефактів ростуть без очищення; шари контейнерів і кеші інструментів накопичуються.

Виправлення: Визначте політику збереження кешів. Додайте скрипти планового очищення для проміжних результатів. Розширте том, якщо ви дійсно будуєте великі артефакти.

Три корпоративні міні‑історії з практики

Міні‑історія 1: Інцидент через неправильне припущення

Середня інженерна організація розгорнула «Dev Drive для всіх» після того, як одна команда помітила прискорення .NET‑збірок. IT створили золотий образ і скрипт, що за замовчуванням переносив робочі простори на D:\ (ReFS). Було акуратно. Але через кілька тижнів це зламалося у спосіб, що здавався надприродним.

Симптомом не була «повільніша збірка». Це були «випадкові помилки збірки на нових машинах». Помилки були непослідовними: хтось бачив відсутність файлів, хтось — проблеми, схожі на права доступу, у інструментів, яким ніколи не було до цього діла. Спільною ниткою були операції Git та застарілий генератор коду, що зберігав стан у шляху, похідному від профілю користувача.

Неправильне припущення: «Якщо працює на моїй машині — працюватиме на всіх». Машина пілота мала інші налаштування політик і іншу версію стека. Генератор припускав можливість створення певного типу посилання і покладався на поведінку NTFS, яку невимушено використовував роками. На ReFS він не падав завжди — падіння відбувалось при конкретній формі шляху та наборі конкурентних операцій.

Виправлення було банальним: розділили навантаження. Код і проміжні файли пішли на Dev Drive, а директорія стану генератора залишилась на невеликому NTFS‑локації; до процесу вступив тест сумісності при налаштуванні. Також навчилися версіонувати розгортання: «Dev Drive увімкнено» стало флагом з планом відкоту, а не одностороннім рішенням.

Міні‑історія 2: Оптимізація, що відбилася боком

Інша корпоративна команда вирішила бути амбітною. Вони прочитали, що антивірус може бити по збірках, і ввели політику: повністю виключити весь Dev Drive зі сканування. Не «режим продуктивності», а повне виключення. Аргументували тим, що диск містить «довірений код».

Через два місяці розробник підтягнув залежність, яка згодом була позначена як шкідлива в upstream. Це не був кінематографічний злам. Ніяких вимог про викуп. Просто неприємний payload, що намагався зберегтися й викрасти токени з локальних інструментів розробника. Єдиною причиною, чому це не пішло далі, були мережеві обмеження, які заблокували підозрілий домен.

Огляд після інциденту був жорстким: вони оптимізували критичний контроль безпеки, бо бачили Defender як «гальмо збірки», а не як частину моделі загроз. Глибша проблема була культурна: продуктивність і безпека не домовлялися, вони боролись.

Виправлений підхід використав модель Dev Drive як задумано: зберегти сканування включеним, але налаштованим для директорій розробки, і покладатися на перевірки на межах (завантаження, виконання, репутація, періодичні перевірки), а не на сканування кожного відкриття файлу в гарячій директорії збірки. Також почали більш ретельно прив’язувати та перевіряти залежності. Продуктивність відновилась, а команда безпеки перестала бути ворогом.

Міні‑історія 3: Нудна, але правильна практика, що врятувала день

Мала платформа‑команда підтримувала монорепо, що використовувалось кількома продуктами. Збірки були повільні, і кожен мав свою теорію: «це IDE», «це мережа», «це новий компілятор», «це Windows». Замість пошуку винного команда створила стандартний бенчмарк і вимагала його в будь‑якому твердженні про продуктивність.

Вони вимірювали три фази окремо: checkout, відновлення залежностей і збірка. Фіксували лічильники затримки диска, топ‑процеси по I/O і завантаження CPU. Потім робили ті самі прогони на NTFS і на Dev Drive після перезавантаження, із тим же комітом і з паузою фонових задач, де можливо.

Результати не були драматичними скрізь. Деякі мови майже не змінилися. Але два робочі процеси — проєкти TypeScript з величезними node_modules і C++ збірка, що генерувала моря дрібних проміжків — стабільно покращились. Не безмежно, але реально зекономили хвилини на ітерацію.

Оскільки у них були базові дані, розгортання стало вибірковим: тільки команди з відповідним I/O‑патерном отримали рекомендацію впроваджувати Dev Drive. Вони уникли загальнофлотного «всім треба» та мали докази, коли керівництво питало, чому робота над продуктивністю не давала однакових результатів для всіх. Нудна практика — дисципліна вимірювань — врятувала і час, і інструменти.

Чеклісти / покроковий план

Покроковий план: впровадити Dev Drive без хаосу

1. Класифікуйте навантаження: чи біль у checkout/restore/indexing (I/O), чи у compile/link/test (CPU)? Виміряйте один репрезентативний прогін.
2. Виберіть розміщення: Помістіть Dev Drive на найшвидший локальний NVMe. Якщо у вас лише один диск — це теж прийнятно, але розподіляйте відповідально.
3. Оберіть форм‑фактор:
   • Використовуйте виділений розділ, якщо це ваша основна щоденна робоча область.
   • Використовуйте VHDX, якщо потрібна портативність і легке «витерти і створити знову».
4. Переносьте лише те, що дає вигоду: репозиторії, кеші пакетів (іноді), вихідні артефакти. Тримайте випадкові завантаження та персональні дані окремо.
5. Перевірте сумісність інструментів: запустіть повний ланцюжок: build, test, package, sign, debug і run.
6. Спостерігайте за Defender: впевніться, що ви випадково не відключили захист у спосіб, неприйнятний для безпеки.
7. Зробіть A/B‑бенчмарк: той самий коміт, ті самі кроки, однакові умови, кілька прогонів. Зберігайте дані.
8. Стандартизуйтесь: задокументуйте, куди йдуть репо, куди кеші і як чистити.
9. Операціоналізуйте очищення: періодичне видалення проміжних файлів і застарілих кешів, особливо для монорепо і мульти‑SDK середовищ.
10. Майте план відкату: якщо команда натрапила на проблему сумісності, повинен бути задокументований шлях назад на NTFS без втрати тижня роботи.

Що робити / чого не робити (бо ви піддастеся спокусі)

• Робіть: розміщуйте високочастотні директорії на Dev Drive (вихідні файли, дерева залежностей з великою кількістю дрібних файлів).
• Робіть: тримайте принаймні 15–20% вільного місця на томі Dev Drive.
• Робіть: фіксуйте лічильники і I/O процесів під час повільних прогоів.
• Не робіть: не виключайте весь Dev Drive зі сканування без моделі загроз і погоджень.
• Не робіть: не думайте, що VHDX дає «безкоштовну продуктивність». Це ще один шар і може посилити конкуренцію за ресурси, якщо хост‑диск зайнятий.
• Не робіть: не розгортайте на весь флот без пілота сумісності, що відповідає реальним стеком інструментів, а не лише одній команді.

Питання та відповіді

1) Чи Dev Drive лише для Visual Studio?

Ні. Йдеться про поведінку файлової системи та безпеки під dev‑типом I/O. Visual Studio отримує вигоду, але також виграють операції Git, екосистеми Node/Java, CMake/Ninja та інші робочі процеси з «багато дрібних файлів».

2) Чи варто використовувати Dev Drive для проєктів WSL2?

Залежить від того, де знаходяться файли. Якщо ви збираєте всередині WSL на нативних Linux‑файлових системах — Dev Drive неактуальний. Якщо збираєте проти Windows‑монтуваних шляхів — Dev Drive може допомогти, але штраф межі між ОС може все одно домінувати.

3) Чи Dev Drive швидше зношує SSD?

Збірки й так багато пишуть. Сам по собі Dev Drive не множить знос, але швидші збірки можуть означати, що ви частіше запускаєте їх — отже більше записів. Практичний контроль — це очищення і обмеження зайвих пересоборів.

4) Чи можна зберігати кеші пакетів на Dev Drive?

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

5) Чому б просто не додати виключення Defender і залишити NTFS?

Бо «виключення» — грубий інструмент і часто використовується надто широко. Dev Drive пропонує безпечніший, структурований підхід до продуктивності. Крім того, ReFS може покращити поведінку при метадантах навіть коли сканування не є єдиною витратою.

6) Чи ReFS надійний для машин розробників?

Він широко використовується у серверних контекстах, і Dev Drive — цілеспрямована клієнтська функція. Але «надійність» також означає «сумісність з інструментами і процесами резервного копіювання». Тестуйте відновлення і відкат, а не лише продуктивність.

7) Який найпоказовіший сигнал, що Dev Drive мені допоможе?

Якщо повільні кроки домінуються обходом файлів та читанням/записом дрібних файлів, і ви бачите, що Defender (або інші драйвери‑фільтри) виконують багато I/O у ці кроки.

8) Що робити, якщо корпоративна політика блокує Dev Drive або ReFS?

Тоді поводьтесь із цим як зі звичайною інженерною зміною: зберіть невелику доказову базу. Покажіть A/B‑таймінги, які фази покращуються, і запропонуйте обмежене розгортання з гарантіями безпеки.

9) Чи варто ставити весь монорепо на Dev Drive?

Зазвичай так, якщо монорепо — джерело вибуху кількості файлів. Але тримайте окремо застарілі компоненти, що ламаються на ReFS. Дозволено змішане розміщення; догма не потрібна.

10) Як зрозуміти, що я вибрав неправильний підхід (розділ vs VHDX)?

Якщо вам потрібна портативність, кілька ізольованих середовищ або швидкий скидання — VHDX ваш вибір. Якщо прагнете абсолютної передбачуваності та простоти — виділений розділ краще. Обирайте за операційними потребами, а не естетикою.

Наступні кроки (практично, не прагматично)

Ось що я б зробив далі, якби відповідав за продуктивність збірок у команді, що сильно залежить від Windows:

1. Виберіть одне репозиторій‑репрезентатив, що найбільше «крутить» і визначте повторюваний бенчмарк: checkout, restore, build, test.
2. Запустіть швидкий план діагностики і класифікуйте вузьке місце. Якщо ви не I/O‑обмежені — припиніть ганятися за налаштуваннями файлової системи.
3. Підніміть Dev Drive на найшвидшому локальному NVMe (розділ чи VHDX), перемістіть репо і повторіть бенчмарк у контрольованих умовах.
4. Спостерігайте за I/O процесу Defender під час прогону. Якщо він у топі — Dev Drive, ймовірно, допомагає; якщо ні — копайте далі.
5. Задокументуйте стандартний макет для репозиторіїв і вихідних артефактів, а також план очищення. Більшість тикетів «моя машина повільна» — це «у диску купа вчорашніх артефактів».
6. Розгортайте вибірково для робочих навантажень, що відповідають I/O‑патерну. Мета — заощадити години розробників, а не почати файлову війну.

Dev Drive — хороший інструмент. Але не диво. Трактуйте його як будь‑яку зміну у продакшні: вимірюйте, обмежуйте вплив, перевіряйте і майте шлях відкату. Так ви отримаєте швидкість без несподіваного простою — на машинах розробників і не тільки.