Windows 11 Dev Drive: Impulso real de velocidad para compilaciones

Qué es realmente Dev Drive (y qué no es)

Dev Drive es una característica de Windows que crea un volumen orientado a desarrolladores, normalmente formateado con ReFS (Resilient File System), y afinado para reducir la “muerte por mil operaciones de archivo” en árboles de compilación. Está emparejado con comportamientos de Microsoft Defender destinados a que el escaneo sea menos disruptivo para directorios de alto cambio.

No es magia. No “hace que tu CPU sea más rápida.” No arregla un proyecto con un grafo de compilación patológico. No convierte un disco duro en un SSD. Ataca principalmente un dolor específico: mucho I/O de archivos pequeños donde el antivirus y la sobrecarga de metadatos del sistema de archivos se convierten en el costo dominante.

Dev Drive viene con protecciones y compensaciones. ReFS se comporta de forma diferente a NTFS. Algunas herramientas asumen peculiaridades de NTFS. Algunas políticas empresariales asumen “solo C:\”. Y las copias de seguridad pueden volverse extrañas si tu organización piensa que “las máquinas de desarrollo no las necesitan” (lo cual es una estrategia audaz).

Si principalmente construyes contenedores en WSL2 con bind mounts hacia rutas de Windows, Dev Drive aún puede importar—porque el dolor frecuentemente está en la frontera del sistema de archivos de Windows, no dentro de Linux. Pero si tu cuello de botella es una compilación limitada por CPU o fallos en cachés remotos, Dev Drive educadamente no hará nada.

Por qué las compilaciones son lentas en Windows: los cuellos de botella reales

Los problemas de rendimiento en compilaciones suelen entrar en tres sabores:

1) Bound por CPU: realmente estás compilando

Cuando compilas unidades de traducción grandes, ejecutas un JIT o haces optimización pesada, el disco es solo un actor de apoyo. Dev Drive no ayudará mucho. Las mejoras vienen de paralelismo, PCHs, compilaciones incrementales, compilación distribuida y no recompilar todo por cambiar un comentario.

2) Bound por I/O en archivos pequeños: el impuesto de “node_modules”

Este es el clásico. Restauraciones de paquetes, checkouts de Git, servidores de lenguaje indexando y sistemas de compilación recorriendo árboles enormes. La unidad no es “lenta” en rendimiento; es lenta en latencia y trabajo de metadatos: abrir, cerrar, statear y escanear una montaña de archivos pequeños.

El antivirus empeora esto porque cada creación/apertura puede activar hooks de escaneo y drivers de filtro. Esa sobrecarga no es constante; se dispara cuando tu compilación genera binarios e intermedios nuevos. Por eso tus compilaciones parecen “aleatoriamente lentas”, que es el peor tipo de lentitud.

3) Comportamiento patológico de herramientas: el asesino silencioso

Algunas herramientas reescanean el árbol repetidamente. Algunas generan enormes cantidades de archivos intermedios. Otras escriben logs de forma síncrona. Algunas usan watchers de archivos que caen al polling y luego castigan a tu almacenamiento. Puedes aplicar ReFS y aun así perder.

Dev Drive apunta directamente a la categoría 2: árboles de desarrollo que son efectivamente un benchmark de metadatos. Si ese eres tú, vale la pena considerarlo seriamente.

Una cita para recordar (idea parafraseada): Gene Kim suele enfatizar que los bucles de retroalimentación rápidos son la base de la entrega efectiva y la confiabilidad. Tu tiempo de compilación es un asunto de confiabilidad.

Broma #1: Si tu compilación necesita una pausa para café, no está “siendo minuciosa”, probablemente está esperando al antivirus.

Datos interesantes y contexto histórico (porque esto no surgió de la nada)

1. ReFS debutó en Windows Server 2012 como un sistema de archivos de siguiente generación centrado en resiliencia e integridad más que en compatibilidad con legado.
2. NTFS data de principios de los años 90. Está probado en batalla, pero arrastra décadas de comportamientos de compatibilidad que no están optimizados para cargas modernas de desarrollo.
3. Windows Defender usa drivers de filtro del sistema de archivos para inspeccionar la actividad. Esto es poderoso—y también una fuente principal de sobrecarga por archivo durante compilaciones.
4. Las cargas de trabajo de desarrolladores han cambiado: “un repo” a menudo significa cientos de miles de archivos una vez incluyes dependencias y artefactos generados.
5. Flujos de trabajo basados en VHD/VHDX son bien conocidos en ops; llevamos años aislando cargas con discos virtuales porque son fáciles de mover, snapshotear y borrar.
6. ReFS históricamente era cosa de servidores, pero Dev Drive lo lleva a máquinas cliente de desarrollo de forma dirigida, no como reemplazo universal.
7. La aceleración de builds solía significar discos más rápidos; ahora con frecuencia significa reducir el “trabajo por archivo” mediante cachés, escaneos más inteligentes y evitar toques innecesarios al sistema de archivos.
8. Las funciones de integridad de archivos tienen un costo. Checksums y verificaciones mejoran la fiabilidad, pero añaden CPU e I/O a menos que se ajusten para la carga.
9. El endurecimiento de la seguridad en Windows ha aumentado con el tiempo, y eso es bueno—hasta que tu directorio de compilación parezca comportamiento malicioso (creación rápida de archivos, compilación, ejecución).

Bajo el capó: ReFS, filtros y por qué Defender importa

ReFS vs NTFS para árboles de desarrollo

ReFS (Resilient File System) está diseñado con suposiciones de almacenamiento modernas: volúmenes grandes, características de integridad y manejo de metadatos que pueden ser más amables bajo actividad paralela intensiva en archivos. Para compilaciones, la implicación práctica suele ser: menos “bloqueos raros” cuando muchos procesos crean y consultan muchos archivos.

Pero ReFS no es un reemplazo directo para cada característica de NTFS que hayas interiorizado. Algunos comportamientos y características específicas de NTFS no están presentes o se comportan distinto. Si tu cadena de herramientas tiene suposiciones antiguas (o depende de compresión NTFS, EFS o ciertos casos límite de reparse-points), debes probar. No lo despliegues como un memo de política.

Defender: no es el villano, pero está en la ruta caliente

Hablando claro: Defender está haciendo su trabajo. Las compilaciones parecen sospechosas. Crean ejecutables, escriben en temporales, descargan paquetes y ejecutan scripts. Un producto de seguridad que ignorara esto sería… creativamente negligente.

La propuesta de Dev Drive no es “apagar la seguridad.” Es “aplicar una postura de escaneo orientada al rendimiento para ubicaciones de desarrollo confiables”, reduciendo el impuesto constante de escanear cada apertura de archivo. Esa es la diferencia entre una configuración pragmática y un incidente de seguridad esperando ocurrir.

El patrón de I/O que Dev Drive apunta

• creación/apertura/cierre de archivos con alta frecuencia
• muchas lecturas concurrentes a través de muchos archivos pequeños
• cambio rápido en directorios intermedios (obj/bin, bazel-out, target, dist, build, .gradle, etc.)
• rutas locales repetibles y “código conocido” donde escanear cada acceso tiene menos valor que escanear en los límites

Si tu compilación hace lecturas/escrituras secuenciales sostenidas y grandes (por ejemplo, activos de video, archivos monolíticos gigantes), Dev Drive puede ser neutral. Tu límite de rendimiento probablemente sea el SSD, el controlador o el throttling térmico—no la ruta de metadatos del sistema de archivos.

Rutas de configuración: partición, VHDX o “por favor no”

Opción A: Partición dedicada (mejor para uso diario serio)

Si puedes permitirte el espacio, un volumen dedicado es sencillo. Letra de unidad predecible, rendimiento estable, menos capas. Si tienes un NVMe rápido y compilas constantemente, esto suele ser lo más limpio.

Úsalo cuando: estés estable en una máquina, tengas derechos de administrador y quieras el comportamiento menos sorprendente.

Opción B: Dev Drive en VHDX (mejor para aislamiento y portabilidad)

Un Dev Drive basado en VHDX es un compromiso sólido: puedes asignarlo dinámicamente, colocarlo en un disco rápido y borrarlo si se corrompe o infla. También facilita “entornos de desarrollo separados”: un VHDX por cliente o por rama mayor.

Úsalo cuando: quieras mantener el SO base limpio, reconstruyas máquinas a menudo o soportes toolchains incompatibles entre sí.

Opción C: Poner toda tu vida en Dev Drive (no lo hagas)

Dev Drive es para código fuente, dependencias y artefactos de compilación. No fotos familiares. No tu gestor de contraseñas. No la carpeta “Downloads” donde aterrizan ejecutables aleatorios. Mantén el radio de explosión pequeño. La postura de seguridad se basa en límites de confianza, y tu árbol de desarrollo debe tratarse como una zona especial, no como toda la ciudad.

Broma #2: Si guardas todo tu directorio personal en Dev Drive, felicitaciones—has inventado “producción” otra vez, pero con menos copias de seguridad.

Tareas prácticas: comandos, salidas y decisiones

Abajo están las tareas reales que ejecutaría en una máquina de desarrollo con Windows 11 cuando alguien dice “Dev Drive no ayudó” o “Dev Drive solucionó todo”. Trataremos ambas afirmaciones con igual sospecha.

Importante: Los comandos se muestran usando PowerShell. Los fragmentos de salida son representativos. Tus valores exactos variarán. Lo importante es lo que aprendes y la decisión que tomas.

Task 1: Confirmar que la build de Windows soporta las funciones de Dev Drive

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

Qué significa: Necesitas una versión moderna de Windows 11 donde Dev Drive esté disponible y estable. Si estás en una build antigua, el comportamiento y las opciones de UI pueden diferir.

Decisión: Si el SO está desactualizado, actualiza primero. No midas una función que no puedes usar completamente.

Task 2: Listar volúmenes y tipos de sistema de archivos (encontrar ReFS vs 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

Qué significa: Tienes un volumen ReFS etiquetado DevDrive. Bien. Si es NTFS, no estás probando el principal ángulo del sistema de archivos de Dev Drive.

Decisión: Si tu “Dev Drive” es en realidad NTFS, para. Arregla eso antes de culpar a la función.

Task 3: Comprobar si el disco es realmente 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

Qué significa: Si MediaType es HDD o BusType es USB, estás optimizando la capa equivocada. Dev Drive no arregla latencia rotacional ni gabinetes externos lentos.

Decisión: Si no es NVMe/SSD, coloca el almacenamiento correctamente antes de afinar el sistema de archivos.

Task 4: Verificar alineación de partición (la desalineación puede perjudicar I/O aleatorio)

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

Qué significa: Un offset de 1,048,576 bytes (1 MiB) es la alineación moderna “buena”. Offsets extraños pueden causar lecturas/escrituras adicionales.

Decisión: Si la alineación es rara (no alrededor de 1 MiB), recrea la partición. No luches contra la física.

Task 5: Ver si Defender está en la ruta caliente para tu árbol de desarrollo

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

Qué significa: Exclusiones mínimas. Eso es normal en entornos muy cerrados. Pero si tu árbol de desarrollo no está tratado especialmente, Defender puede escanear agresivamente.

Decisión: Si la política corporativa lo permite, configura Dev Drive correctamente en lugar de esparcir exclusiones amplias por todos lados.

Task 6: Confirmar el estado de protección en tiempo real de Defender (no asumas)

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

Qué significa: Defender está activo. Bien. Ahora debes tratar el ajuste de rendimiento como “hacer el escaneo más inteligente”, no “apagarlo”.

Decisión: Si pensabas que Defender estaba apagado y está encendido, tus suposiciones de benchmark ya están rotas.

Task 7: Medir el impacto de Defender con una prueba controlada de recorrido de archivos

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

Qué significa: Esto es una herramienta burda, pero útil. El recorrido de directorios es una gran parte de muchas compilaciones (globbing, escaneo de dependencias, indexado).

Decisión: Ejecuta la misma prueba en una ubicación NTFS con el mismo repo. Si ReFS + Dev Drive es significativamente más rápido, estás en la zona objetivo.

Task 8: Comprobar indexación de Windows Search en el volumen de desarrollo

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

Qué significa: La indexación puede añadir I/O en segundo plano y actividad de apertura de archivos. No siempre es terrible, pero a veces compite con tu carga.

Decisión: Si las compilaciones son inestables durante la indexación, reduce las ubicaciones indexadas o excluye el volumen de desarrollo de la indexación (si la política lo permite).

Task 9: Comprobar colas de disco y latencia durante una compilación real

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

Qué significa: Milisegundos de un solo dígito están bien. Cuando ves decenas de milisegundos y colas altas, estás limitado por el almacenamiento (o te están limitando).

Decisión: Si la latencia se dispara durante la restauración de dependencias y la generación de archivos, Dev Drive es relevante. Si la latencia es plana pero la CPU está al tope, busca en otra parte.

Task 10: Identificar qué procesos están golpeando fuerte el disco

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

Qué significa: Si MsMpEng (Defender) está arriba durante las compilaciones, has encontrado un gran sospechoso. Si son tu compilador y enlazador, quizá simplemente estás compilando mucho.

Decisión: Alto I/O de MsMpEng sugiere que necesitas configurar Dev Drive correctamente y/o límites de escaneo más inteligentes.

Task 11: Validar que tu repo está en el volumen previsto

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

Qué significa: Te sorprendería la frecuencia con que la gente mide “Dev Drive” mientras su repo real está en C:\ debido a un symlink, una IDE mal configurada o memoria muscular.

Decisión: Si el repo no está en Dev Drive, muévelo. Luego vuelve a probar.

Task 12: Detectar reparse points y rarezas de symlink en el repo

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

Qué significa: Algunas herramientas y escáneres se comportan mal alrededor de junctions/symlinks, causando reescaneos repetidos o incluso ciclos.

Decisión: Si ves muchos reparse points, asegúrate de que tus herramientas y reglas de escaneo de seguridad los manejen correctamente. Considera aplanar el layout si es patológico.

Task 13: Comprobar espacio libre y riesgo de fragmentación (sí, incluso en 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

Qué significa: Las cargas de trabajo de desarrollo se inflan rápido. Poco espacio libre aumenta la amplificación de escrituras y puede activar comportamientos desagradables del SSD.

Decisión: Si estás por debajo de ~15–20% de espacio libre, amplía el volumen o limpia cachés de compilación. No “optimices” un disco casi lleno.

Task 14: Buscar throttling térmico y problemas de configuración de energía

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

Qué significa: El modo Balanced suele estar bien, pero los portátiles bajo carga de compilación pueden bajar el reloj de la CPU o estrangular el almacenamiento por calor.

Decisión: Si ves caída de rendimiento tras unos minutos, prueba en “Mejor rendimiento” y vigila las temperaturas. Dev Drive no arreglará un portátil que se sobrecalienta.

Task 15: Comprobar que tu compilación es realmente incremental

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

Qué significa: Directorios de compilación enormes pueden ser normales, pero si crecen sin control pagas por escaneos y recorridos adicionales en cada ejecución.

Decisión: Si la cantidad de artefactos se dispara, añade políticas de limpieza y asegúrate de que tu herramienta de compilación no esté mal configurada para desactivar el comportamiento incremental.

Playbook de diagnóstico rápido (encuentra el cuello de botella en 15 minutos)

Esta es la secuencia de “deja de debatir y mide”. Hazlo en orden. Cada paso o confirma que Dev Drive es la palanca correcta—o te dice que dejes de perder el tiempo.

Primero: Decide si estás bound por I/O o por CPU

• Comprueba saturación de CPU: si todos los núcleos están al máximo y la latencia de disco se mantiene baja, Dev Drive no será el héroe.
• Comprueba latencia de disco y longitud de cola durante el paso lento: si la latencia sube y la longitud de cola aumenta, estás bound por I/O.

Segundo: Identifica si el escaneo de seguridad es el impuesto

• Si MsMpEng está entre los procesos con más I/O durante las compilaciones, Defender está involucrado materialmente.
• Si el I/O de Defender es bajo, enfócate en las herramientas (resolver de dependencias, enlazador, watcher de archivos) o en el hardware de almacenamiento.

Tercero: Prueba que la capa de almacenamiento es lo que piensas

• Confirma que el repo está en el volumen Dev Drive.
• Confirma que ese volumen está en SSD/NVMe (no en un “disco rápido” externo que en realidad es un cuello de botella).
• Confirma espacio libre y ausencia de problemas de configuración obvios (indexación, agentes de backup, herramientas de sincronización).

Cuarto: Usa una prueba A/B, no sensaciones

Toma una operación representativa: checkout limpio + restauración de paquetes + compilación. Ejecútala en NTFS y en Dev Drive, misma máquina, mismo commit, misma red, mismo modo de energía. Si la delta está dentro del ruido, Dev Drive no es tu limitador.

Errores comunes (síntoma → causa raíz → solución)

1) “Dev Drive no hizo nada.”

Síntoma: Tiempos de compilación sin cambios después de mover el repo.

Causa raíz: La fase lenta está bound por CPU (compilación/enlazado) o por red (descargas de paquetes).

Solución: Perfiliza las fases de compilación. Si es CPU-bound, mejora compilaciones incrementales, paralelismo y cachés. Si es red-bound, usa caches locales, mirrors o lockfiles. Dev Drive no acelera la red.

2) “Dev Drive es más lento que C:\.”

Síntoma: Operaciones de archivo lentas; indexado del IDE más lento.

Causa raíz: Dev Drive colocado en almacenamiento más lento (SSD secundario, gabinete externo) o dentro de un VHDX limitado en un disco ocupado.

Solución: Coloca Dev Drive en el NVMe local más rápido. Si usas VHDX, asegúrate de que el disco host tenga margen y no comparta cargas pesadas (clientes de sincronización, imágenes VM, juegos—sí, los juegos cuentan como generadores de I/O).

3) “Mi cadena de herramientas se rompió tras mover a Dev Drive.”

Síntoma: Hooks de Git fallan, pasos de compilación dan error, problemas de permisos extraños.

Causa raíz: La herramienta depende de comportamiento específico de NTFS, suposiciones de rutas o una política empresarial codificada a C:\.

Solución: Valida la compatibilidad de la herramienta con ReFS. Cuando sea necesario, conserva directorios específicos en NTFS (p. ej., herramientas legacy) y pon los artefactos ruidosos en Dev Drive. Divide la carga en lugar de forzar pureza.

4) “La restauración de paquetes sigue lenta.”

Síntoma: npm/pnpm/yarn, NuGet, Maven/Gradle tardan una eternidad.

Causa raíz: Latencia de red, inspección TLS o un proxy corporativo haciendo análisis profundo. El sistema de archivos local no es el cuello de botella.

Solución: Mide el tiempo de descarga por separado del tiempo de extracción. Usa caches locales cuando esté permitido. Si la inspección TLS es el cuello de botella, escala con evidencia; no te limites a quejarte.

5) “Mi disco es rápido pero las compilaciones son inconsistentes.”

Síntoma: Algunas ejecuciones son rápidas, otras lentas, sin cambios de código.

Causa raíz: Tareas en segundo plano: indexación, clientes de sync, agentes de backup, scans completos de Defender o Windows Update.

Solución: Revisa los procesos que más I/O hacen durante las ejecuciones lentas. Programa trabajos pesados fuera de horas de desarrollo o excluye Dev Drive de la indexación si la política lo permite.

6) “Las compilaciones en WSL son lentas aunque Linux es rápido.”

Síntoma: Compilar en WSL2 es lento cuando el repo está bajo /mnt/c u otra ruta montada en Windows.

Causa raíz: Sobrecarga de la frontera entre sistemas de archivos de ambos OS. Muchas llamadas de metadatos cruzan esa frontera.

Solución: Mantén el repo dentro del sistema de archivos de WSL para compilaciones nativas en Linux, o usa Dev Drive y prueba si la penalización de la frontera baja lo suficiente. No asumas; mide.

7) “Dev Drive se llenó al instante.”

Síntoma: Pierdes decenas de GB en una semana.

Causa raíz: Cachés de compilación y directorios de artefactos crecen sin limpieza; capas de contenedor y caches de herramientas se acumulan.

Solución: Define políticas de retención de cachés. Añade scripts programados de limpieza para salidas de compilación. Amplía el volumen si realmente generas salidas grandes.

Tres minihistorias corporativas desde las trincheras

Mini-historia 1: El incidente causado por una suposición errónea

Una organización de ingeniería mediana desplegó “Dev Drive para todos” después de que un equipo vio compilaciones .NET más rápidas. IT creó una imagen dorada y un script que movía los espacios de trabajo a D:\ (ReFS) por defecto. Parecía ordenado. También se rompió unas semanas después de una forma que parecía sobrenatural.

El síntoma no fue “compilación más lenta.” Fue “compilaciones que fallan aleatoriamente en máquinas nuevas.” Los errores eran inconsistentes: algunos desarrolladores veían errores de archivo faltante, otros fallos parecidos a permisos en herramientas que nunca se habían preocupado por permisos. El hilo común eran operaciones de Git y un generador de código legacy que almacenaba estado en una ruta derivada del perfil de usuario.

La suposición equivocada: “Si funciona en mi máquina, funciona para toda la flota.” La máquina piloto tenía una política diferente y una versión distinta de la cadena de herramientas. El generador asumía que podía crear cierto tipo de enlace y dependía de un comportamiento de NTFS que había usado en silencio durante años. Al colocarlo en ReFS, no fallaba siempre. Fallaba cuando encontraba una forma de ruta específica y un conjunto específico de operaciones concurrentes.

La solución fue aburrida: dividieron la carga. Fuente e intermedios fueron a Dev Drive, pero el directorio de estado del generador quedó en una pequeña ubicación NTFS, y se añadió una prueba de compatibilidad al onboarding. También aprendieron a versionar el despliegue: “Dev Drive activado” pasó a ser una bandera de función con plan de reversión, no una calle de un solo sentido.

Mini-historia 2: La optimización que salió mal

Un equipo empresarial distinto se puso ambicioso. Leyeron que el escaneo antivirus puede golpear las compilaciones, así que impusieron una política: excluir todo el Dev Drive del escaneo. No “modo rendimiento.” Exclusión total. Lo justificaron diciendo que la unidad solo contenía “código confiable”.

Dos meses después, un desarrollador descargó una dependencia que luego fue marcada como maliciosa upstream. No fue una brecha cinematográfica. Ninguna nota de rescate. Solo una carga dañina que intentó persistir y exfiltrar tokens de las herramientas locales de desarrollo. La única razón por la que no fue peor es que los controles de salida de red bloquearon un dominio sospechoso.

La revisión post-incidente fue contundente: optimizaron hasta sacrificar un control crítico de seguridad porque veían a Defender como “una ralentización de builds”, no como parte del modelo de amenazas. El problema más profundo fue cultural: rendimiento y seguridad no negociaban; peleaban.

El enfoque corregido usó el modelo previsto de Dev Drive: mantener el escaneo activado, pero afinado para directorios de desarrollo, y apoyarse en cheques de frontera (descargas, ejecución, reputación y escaneos periódicos) en lugar de escanear cada apertura de archivo en un árbol caliente de compilación. También empezaron a fijar y verificar dependencias con más rigor. El rendimiento se recuperó y el equipo de seguridad dejó de afilar cuchillos.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Un pequeño equipo de plataforma soportaba un monorepo usado por varios grupos de producto. Las compilaciones eran lentas y todos tenían una teoría: “Es el IDE”, “Es la red”, “Es el compilador nuevo”, “Es Windows siendo Windows”. En vez de elegir un villano, el equipo creó un script de benchmark estándar y lo exigió para cualquier reclamo de rendimiento.

Midieron tres fases por separado: checkout, restauración de dependencias y compilación. Capturaron contadores de latencia de disco, procesos top en I/O y uso de CPU. Luego repitieron la misma ejecución en NTFS y en Dev Drive, tras un reboot, con el mismo commit y con tareas en segundo plano pausadas donde fue posible.

Los resultados no fueron dramáticos en todos los casos. Algunos lenguajes tuvieron poco cambio. Pero dos flujos de trabajo—proyectos TypeScript con enormes node_modules y un sistema C++ que generaba océanos de intermedios pequeños—mejoraron consistentemente. No velocidad infinita, pero minutos reales ahorrados por iteración.

Porque tenían datos base, el despliegue fue quirúrgico: solo a los equipos con patrones de I/O coincidentes se les recomendó adoptar Dev Drive. Evitaron un mandato de “todos deben” para la flota, y tuvieron pruebas cuando la dirección preguntó por qué el trabajo de rendimiento no era uniforme. La práctica aburrida fue disciplina de medición, y evitó tiempo perdido y toolchains rotos.

Listas de verificación / plan paso a paso

Plan paso a paso: adoptar Dev Drive sin crear un desastre

1. Clasifica tu carga: ¿El dolor está en checkout/restore/indexado (I/O) o compile/link/test (CPU)? Mide una ejecución representativa.
2. Elige ubicación: Pon Dev Drive en el NVMe local más rápido. Si solo tienes un disco, sigue siendo aceptable—simplemente asigna responsablemente.
3. Elige formato:
   • Usa una partición dedicada si este es tu workspace diario primario.
   • Usa un VHDX si quieres portabilidad y fácil “wipe and recreate”.
4. Mueve solo lo que se beneficia: repos, cachés de paquetes (a veces), salidas de compilación. Mantén descargas aleatorias y datos personales en otro lugar.
5. Valida compatibilidad de herramientas: ejecuta la cadena completa: build, test, empaquetado, firmar, depurar y ejecutar.
6. Observa el comportamiento de Defender: confirma que no deshabilitaste protecciones de forma que seguridad no acepte.
7. Benchmark A/B: mismo commit, mismos pasos, mismas condiciones, múltiples ejecuciones. Guarda los datos.
8. Estandariza: documenta dónde van los repos, dónde van las cachés y cómo limpiar.
9. Operacionaliza la limpieza: remoción periódica de intermedios y cachés obsoletos, especialmente para monorepos y entornos multi-SDK.
10. Crea un plan de reversión: si un equipo encuentra un problema de compatibilidad, necesita una vía documentada de escape a NTFS sin perder una semana.

Lista de hacer / no hacer (porque te sentirás tentado)

• Hacer: pon directorios de alto cambio en Dev Drive (salidas de compilación, árboles de dependencias que explotan en muchos archivos pequeños).
• Hacer: mantén al menos 15–20% de espacio libre en el volumen Dev Drive.
• Hacer: captura contadores y I/O de procesos durante ejecuciones lentas.
• No hacer: excluir en bloque todo el Dev Drive del escaneo de seguridad sin un modelo de amenazas y aprobaciones.
• No hacer: asumir que VHDX significa “rendimiento gratis.” Es otra capa y puede amplificar la contención si el disco host está ocupado.
• No hacer: desplegar a toda la flota sin un piloto de compatibilidad que refleje cadenas de herramientas reales, no solo la de un equipo.

Preguntas frecuentes

1) ¿Dev Drive es solo para Visual Studio?

No. Se trata del comportamiento del sistema de archivos y la seguridad bajo I/O tipo desarrollo. Visual Studio se beneficia, pero también operaciones de Git, ecosistemas Node/Java, CMake/Ninja y otros flujos con “muchos archivos pequeños”.

2) ¿Debería usar Dev Drive para proyectos WSL2?

Depende de dónde residan los archivos. Si compilas dentro de WSL en sistemas de archivos nativos de Linux, Dev Drive es irrelevante. Si compilas contra rutas montadas de Windows, Dev Drive puede ayudar, pero la penalidad de la frontera cruzada aún puede dominar.

3) ¿Dev Drive hará que mi SSD se desgaste más rápido?

Las compilaciones ya escriben mucho. Dev Drive en sí no es un “multiplicador de desgaste”, pero compilaciones más rápidas pueden significar que haces más compilaciones, lo que implica más escrituras. El control práctico es limpieza y limitar recompilaciones innecesarias.

4) ¿Puedo almacenar caches de paquetes en Dev Drive?

Con frecuencia sí, y puede ayudar. Pero las caches también son un límite de seguridad. Si tu organización audita caches o depende de escanearlas, coordina con seguridad antes de reubicarlas.

5) ¿Por qué no simplemente añadir exclusiones de Defender y mantener NTFS?

Porque las “exclusiones” son una herramienta tosca y frecuentemente mal usada. Dev Drive pretende una postura de rendimiento más estructurada y segura. Además, ReFS puede mejorar el comportamiento intensivo en metadatos incluso cuando el escaneo no es el único costo.

6) ¿ReFS es fiable para máquinas de desarrollador?

Se usa ampliamente en servidores, y Dev Drive es una característica dirigida al cliente. Pero “fiable” también significa “compatible con tus herramientas y flujos de backup”. Prueba restauración y recuperación, no solo el rendimiento.

7) ¿Cuál es la señal más clara de que Dev Drive me ayudará?

Los pasos lentos están dominados por enumeración de archivos y lecturas/escrituras de archivos diminutos, y ves que Defender (u otros drivers de filtro) realizan mucho I/O durante esas fases.

8) ¿Qué pasa si mi política empresarial bloquea Dev Drive o ReFS?

Entonces trátalo como cualquier otro cambio de ingeniería: construye un caso con evidencia. Muestra tiempos A/B, muestra qué fase mejora y propone un despliegue restringido con guardrails.

9) ¿Debería poner todo mi monorepo en Dev Drive?

Usualmente sí, si el monorepo es la fuente de la explosión de conteo de archivos. Pero separa componentes legacy que rompen en ReFS. La colocación mixta está permitida; el dogma es opcional.

10) ¿Cómo sé si elegí el enfoque equivocado (partición vs VHDX)?

Si necesitas portabilidad, múltiples entornos aislados o reinicio rápido, VHDX es tu amigo. Si buscas predictibilidad absoluta y simplicidad, una partición dedicada gana. Elige según operaciones, no estética.

Siguientes pasos (prácticos, no aspiracionales)

Esto es lo que haría si fuera responsable del rendimiento de compilaciones en un equipo centrado en Windows:

1. Elige un repo representativo que más duela y define un benchmark repetible: checkout, restore, build, test.
2. Ejecuta el playbook de diagnóstico rápido y clasifica el cuello de botella. Si no estás bound por I/O, deja de perseguir ajustes de almacenamiento.
3. Levanta un Dev Drive en el NVMe local más rápido (partición o VHDX), mueve el repo y vuelve a ejecutar el benchmark en condiciones controladas.
4. Observa el I/O del proceso Defender durante la ejecución. Si es un actor principal, Dev Drive probablemente aporta; si no, sigue investigando.
5. Documenta un layout estándar para repos y salidas de compilación, más un plan de limpieza. La mayoría de los tickets de “mi máquina es lenta” son en realidad “mi disco está lleno de artefactos de ayer”.
6. Despliega selectivamente a las cargas que coincidan con el patrón de I/O. El objetivo es menos horas desperdiciadas por desarrollador, no una cruzada por un sistema de archivos.

Dev Drive es una buena herramienta. No es un milagro. Trátalo como cualquier cambio en producción: mide, restringe, valida y ten una vía de reversión. Así obtienes velocidad sin sorpresas—en máquinas de desarrollo o en cualquier otro lugar.