Unità di sviluppo Windows Dev Drive alla prova: vale davvero la pena usarla?

Chi sviluppa software su Windows conosce bene una situazione apparentemente paradossale: anche con un SSD NVMe molto veloce, capace di trasferire diversi gigabyte al secondo, alcune operazioni tipiche dello sviluppo possono richiedere tanto tempo. Succede, ad esempio, durante un npm install, il ripristino di numerosi pacchetti NuGet, la compilazione di progetti molto estesi oppure quando Git deve passare da un ramo all’altro e aggiornare sul disco decine di migliaia di file.

Il problema, infatti, non dipende necessariamente dalla velocità sequenziale dell’unità SSD. Nei carichi legati alla programmazione software entrano in gioco la gestione dei metadati, l’apertura e chiusura continua di migliaia di file, le copie, i controlli del file system e soprattutto l’intervento dei filtri che Windows inserisce lungo il percorso delle operazioni I/O.

Windows Dev Drive o Unità di sviluppo in italiano è una funzionalità di Windows 11 ancora poco conosciuta anche fra gli sviluppatori che aiuta a migliorare significativamente l’assetto.

Cosa sono e come funzionano le Unità di sviluppo (Windows Dev Drive) in Windows 11

Microsoft descrive le Unità di sviluppo come un volume di archiviazione espressamente ottimizzato per i principali carichi di lavoro correlati alle attività di sviluppo.

Non si tratta semplicemente di creare una partizione separata o di assegnare una nuova lettera di unità: Windows formatta il volume utilizzando ReFS (Resilient File System) e applica una serie di impostazioni pensate per repository di sorgenti, cache dei pacchetti software, file intermedi e risultati delle compilazioni.

Windows continua a utilizzare NTFS per l’unità di sistema e per la maggior parte dei volumi tradizionali. Unità di sviluppo utilizza invece ReFS, file system progettato da Microsoft con particolare attenzione alla scalabilità, all’integrità dei dati e alla gestione efficiente di determinati tipi di operazioni.

Microsoft ha introdotto in ReFS alcune ottimizzazioni che risultano particolarmente utili quando un’applicazione deve manipolare quantità molto elevate di file. È una situazione comune nello sviluppo moderno: basti pensare alla directory node_modules di un progetto JavaScript, alla cache NuGet di .NET, ai pacchetti Python, agli artefatti generati da una compilazione C++ oppure alle directory gestite da Maven, Gradle e Cargo.

La velocità massima dichiarata dall’SSD racconta poco di questi scenari. Un’unità da 7 GB/s può essere velocissima quando copia un singolo file di grandi dimensioni, ma un’operazione che coinvolge 100.000 piccoli file richiede una quantità enorme di aggiornamenti ai metadati, aperture, verifiche, chiamate al file system e interventi dei componenti di sicurezza.

Unità di sviluppo cerca quindi di ridurre il costo complessivo di tali operazioni anziché inseguire semplicemente una maggiore velocità del dispositivo fisico.

Il vero asso nella manica è Microsoft Defender ottimizzato

Una delle caratteristiche più interessanti di Unità di sviluppo riguarda un componente che, almeno apparentemente, non ha nulla a che fare con il file system: Microsoft Defender.

Ogni accesso ai file può infatti coinvolgere l’antivirus: durante una compilazione, un git checkout, l’estrazione di un pacchetto oppure l’installazione delle dipendenze, il numero di operazioni può diventare enorme.

Su un normale volume Windows, Microsoft Defender utilizza la protezione in tempo reale ed effettua i controlli nel percorso in cui ciascuna operazione è svolta: la scansione dei file può contribuire alla latenza percepita dall’applicazione.

L’Unità di sviluppo è considerata un volume “affidabile” (trusted, in inglese) quindi Defender può in questo caso utilizzare la sua modalità prestazioni.

In questa specifica modalità, la scansione può essere posticipata fino a dopo il completamento dell’operazione di apertura del file. Il controllo diventa quindi asincrono, riducendo l’impatto della scansione sul programma che sta manipolando il file.

I file-system filter spiegano un’altra parte del guadagno

C’è poi una caratteristica di Unità di sviluppo che contribuisce a migliorare le prestazioni.

Windows utilizza numerosi file-system filter, componenti che intercettano le operazioni sui file per aggiungere funzionalità come antivirus, cifratura, controllo delle applicazioni, monitoraggio e altre forme di protezione. Ogni filtro inserito nel percorso I/O ha inevitabilmente un costo.

Nel caso di un’Unità di sviluppo trusted, Windows adotta una politica molto più restrittiva: il File System Filter Manager disattiva per impostazione predefinita i filtri non necessari, mantenendo i filtri antivirus previsti dalla configurazione. Gli amministratori possono poi creare un elenco di filtri autorizzati qualora un determinato software ne abbia bisogno.

Windows 11 aggiunge alle Unità di sviluppo anche il block cloning

Un altro tassello importante è il block cloning, sfruttabile sui volumi ReFS e quindi particolarmente interessante in abbinamento con Unità di sviluppo.

Immaginiamo un’applicazione che debba duplicare un file molto grande. La modalità tradizionale prevede la lettura dei dati dalla sorgente e la loro riscrittura nella destinazione. Con il block cloning di ReFS, invece, il file system può inizialmente creare riferimenti ai medesimi blocchi fisici, modificando essenzialmente i metadati.

Microsoft descrive l’operazione come una copia di un intervallo di byte realizzata senza eseguire le costose operazioni di lettura e riscrittura dei dati sottostanti.

Il principio ricorda lo schema proprio della tecnica Copy-on-Write: finché le copie rimangono identiche, possono condividere gli stessi dati; quando una delle due cambia, il file system separa le parti interessate.

Microsoft aveva già sperimentato questa tecnica nei processi di compilazione tramite l’estensione Microsoft.Build.CopyOnWrite. In alcuni test interni pubblicati dall’azienda, l’uso di Unità di sviluppo insieme al Copy-on-Write aveva prodotto miglioramenti considerevoli, anche se quei risultati vanno letti tenendo presenti hardware, progetto e metodologia utilizzati.

Quanto è più veloce un’Unità di sviluppo?

Microsoft, nei test pubblicati in occasione dell’introduzione di Dev Drive, parlava di un miglioramento medio intorno al 25% per attività quali clonazione di repository, compilazione, copia di file e ripristino dei pacchetti. Al solito, però, i risultati riscontrati da ciascuno sviluppatore dipendono enormemente dal carico di lavoro.

Se una compilazione trascorre quasi tutto il tempo saturando tutti i core della CPU, cambiare file system può incidere poco. Se il processo passa invece continuamente da migliaia di letture, scritture, creazioni e cancellazioni di piccoli file, il margine cresce.

Alcuni sviluppatori riferiscono benefici chiaramente percepibili con codebase grandi e sottolineano l’importanza della scansione asincrona di Defender; un altro utente segnala compilazioni Go sensibilmente più veloci dopo aver spostato sull’Unità di sviluppo anche gli strumenti correlati.

Altri dichiarano invece di non aver notato differenze apprezzabili oppure ritengono che, usando già SSD M.2 molto veloci e lavorando con progetti che non dipendono pesantemente dall’I/O, il vantaggio non giustifichi la modifica della configurazione.

Dove Unità di sviluppo può fare davvero la differenza

Il primo campo applicativo è quello dei repository molto grandi, soprattutto quando Git deve creare, modificare o eliminare quantità considerevoli di file.

Operazioni come git clone, git checkout, cambio di branch, git reset --hard, rebase di grandi basi di codice e aggiornamento di working tree molto popolati producono un traffico I/O completamente diverso da quello generato dalla semplice apertura di un file sorgente.

Un repository da pochi gigabyte composto da centinaia di migliaia di file può risultare molto più impegnativo per il file system di un archivio da decine di gigabyte formato da pochi file di grandi dimensioni. Ogni elemento comporta infatti operazioni sui metadati, controlli di sicurezza, apertura di handle e aggiornamenti della struttura delle directory.

Un secondo campo applicativo riguarda i package manager. JavaScript e TypeScript rappresentano probabilmente il caso più evidente: npm, pnpm e Yarn possono creare strutture con un numero elevatissimo di file e directory. Spostare repository e soprattutto cache dei pacchetti sull’Unità di sviluppo consente di concentrare sul volume ottimizzato proprio le operazioni che generano più attività sul file system.

Lo stesso concetto riguarda .NET e NuGet: un dotnet restore o il ripristino dei package effettuato da Visual Studio può richiedere la consultazione, estrazione e verifica di numerosi pacchetti. La documentazione Microsoft dedica una sezione specifica alle cache dei pacchetti e spiega come trasferire sull’Unità di sviluppo la cartella global-packages utilizzata da NuGet, dotnet, MSBuild e Visual Studio.

I linguaggi e gli strumenti che ne beneficiano di più

I vantaggi dell’Unità di sviluppo non riguardano soltanto Node.js o .NET.

Anche progetti C e C++ possono beneficiarne, soprattutto quando le compilazioni generano grandi quantità di file temporanei, librerie e artefatti intermedi; in questi casi si può spostare sul volume anche la cache binaria di vcpkg.

Lo stesso principio vale per Python: Microsoft suggerisce di trasferire la cache di pip; per Rust, il consiglio riguarda le cache e gli output gestiti da Cargo; per Java, le Unità di sviluppo sono utili per la gestione di Maven e Gradle, che possono accumulare molti gigabyte di dipendenze e file di build.

Anche Go utilizza cache di compilazione e moduli che possono generare numerose operazioni sul disco. In tutti questi casi il vantaggio non dipende tanto dal linguaggio usato, quanto dalla quantità di file che strumenti, package manager e sistemi di compilazione devono continuamente creare, leggere e aggiornare.

Come creare davvero un’Unità di sviluppo in Windows 11

Se si vuole provare Unità di sviluppo su un PC già utilizzato quotidianamente, non serve reinstallare Windows 11 e non è necessario dedicare un secondo SSD. È possibile ricavare lo spazio necessario dal disco esistente, a condizione di avere almeno 50 GB disponibili. Microsoft raccomanda inoltre almeno 16 GB di RAM, pur indicando 8 GB come requisito minimo consigliato.

Per iniziare a lavorare con Unità di sviluppo, basta premere Windows+I, scegliere Sistema, Archiviazione, Impostazioni di archiviazione avanzate, Dischi & volumi quindi Crea unità di sviluppo.

Le possibilità tra le quali si può scegliere sono tre:

• Crea un nuovo disco rigido virtuale. Windows crea un file .vhdx, montato come se fosse un disco vero e proprio. È la soluzione meno invasiva per chi vuole semplicemente provare la funzione senza modificare la tabella delle partizioni.
• Ridimensiona un volume esistente. È probabilmente la soluzione più interessante per una workstation usata stabilmente per programmare: si può ridurre, ad esempio, la partizione C: e destinare una parte dello spazio liberato a una nuova Unità di sviluppo.
• Utilizzo dello spazio non allocato. In presenza di un eventuale blocco di spazio non allocato, è possibile selezionarlo e creare direttamente il nuovo volume.

C’è però una limitazione fondamentale: un volume NTFS preesistente non può essere trasformato direttamente in Unità di sviluppo preservandone il contenuto. La designazione avviene al momento della formattazione e comporta l’utilizzo di ReFS. Se si dispone già di una partizione D: piena di progetti, quindi, non basta premere un pulsante per convertirla: bisogna prima spostare i dati, ricreare il volume e poi copiarli nuovamente.

Il metodo più semplice: creare un file VHDX

Come anticipato in precedenza, per chi vuole sperimentare Unità di sviluppo senza toccare le partizioni, il percorso più prudente è probabilmente l’uso di un’unità virtuale in formato VHDX.

Dopo aver scelto Crea un nuovo disco rigido virtuale, Windows 11 chiede innanzitutto dove memorizzare il disco virtuale. A quel punto si sceglie la dimensione: il minimo previsto è 50 GB, ma per un ambiente di sviluppo reale è facile superare rapidamente questa soglia: repository, node_modules, cache NuGet, SDK e output delle build possono occupare decine di gigabyte.

Come formato è preferibile proprio VHDX, che Microsoft raccomanda rispetto al vecchio VHD: supporta dischi virtuali molto più grandi e offre maggiore resilienza in caso di interruzioni impreviste delle operazioni I/O.

Windows 11 permette poi di scegliere tra:

• Dimensione fissa, che alloca immediatamente sul disco host tutto lo spazio richiesto;
• Espansione dinamica, con un file VHDX che cresce progressivamente man mano che vengono scritti dati.

Una volta terminata la procedura, Windows monta il file VHDX e assegna al volume una normale lettera di unità: da questo momento l’unità può essere utilizzata come qualsiasi altro disco.

Meglio una partizione vera se l’Unità di sviluppo diventa permanente

Il VHDX è molto comodo per fare prove, ma chi decide di utilizzare stabilmente Unità di sviluppo può preferire una partizione reale. La ragione è semplice: il volume accede direttamente al dispositivo fisico senza lo strato aggiuntivo rappresentato dal disco virtuale: una partizione tende a fornire prestazioni migliori.

Per crearla senza reinstallare Windows si può utilizzare direttamente la procedura proposta nelle Impostazioni.

Selezionando Ridimensiona un volume esistente, Windows 11 mostra le partizioni che possono essere ridotte. Il file system è automaticamente predisposto secondo i requisiti dell’Unità di sviluppo.

La procedura grafica ha un vantaggio importante rispetto all’uso manuale di Gestione disco: Windows 11 gestisce direttamente la creazione del volume con la corretta designazione Dev Drive.

Si può fare anche da PowerShell

Gli amministratori e chi configura più workstation possono evitare completamente l’interfaccia grafica. Se esiste già un volume che si può formattare, Microsoft mette a disposizione la seguente cmdlet da eseguire in PowerShell con privilegi amministrativi:

Format-Volume -DriveLetter D -DevDrive

In alternativa, dal Prompt dei comandi o dalla stessa finestra PowerShell si può utilizzare:

Format D: /DevDrv /Q

Il parametro /DevDrv indica esplicitamente a Windows di creare un volume destinato ai workload di sviluppo.

Ovviamente va prestata particolare attenzione al fatto che l’operazione di formattazione cancella il contenuto del volume indicato. Prima di eseguire uno di questi comandi è quindi essenziale verificare la lettera dell’unità.

Le due modalità sono documentate da Microsoft nella sezione dedicata alla creazione di Unità di sviluppo dalla riga di comando.

Cosa spostare davvero sull’Unità di sviluppo

Una volta creata l’Unità di sviluppo, il punto non è trasferirvi Windows o reinstallare gli strumenti di lavoro. Visual Studio, VS Code, Git, Node.js, Python, JDK e .NET SDK possono continuare a risiedere su C:. Conviene invece spostare sul nuovo volume tutto ciò che genera molte operazioni di lettura e scrittura: repository, dipendenze, cache dei package, file intermedi e output delle compilazioni.

Una struttura semplice potrebbe essere la seguente:

• D:\src\ repository e progetti
• D:\packages\ cache dei package manager
• D:\build\ file temporanei e output delle build

I repository possono essere clonati direttamente sull’Unità di sviluppo:

cd D:\src
git clone https://github.com/azienda/progetto.git

In questo modo sorgenti, directory .git, dipendenze locali e gran parte dei file generati dal progetto restano sul volume ReFS.

Spostare anche le cache dei package

Per sfruttare meglio l’Unità di sviluppo conviene spostare anche le cache utilizzate dagli strumenti di sviluppo. Microsoft documenta esplicitamente questa possibilità per npm, NuGet, pip, Cargo, Maven e Gradle.

Con npm, ad esempio, si può impartire la seguente istruzione:

npm config set cache D:\packages\npm --global

• Per NuGet si può impostare: NUGET_PACKAGES=D:\packages\nuget
• Con Python: PIP_CACHE_DIR=D:\packages\pip
• Nel caso di Rust: CARGO_HOME=D:\packages\cargo
• Per Gradle: GRADLE_USER_HOME=D:\packages\gradle
• Maven permette invece di indicare un repository locale diverso modificando il file %USERPROFILE%\.m2\settings.xml

La documentazione Microsoft spiega come spostare le cache dei package sull’Unità di sviluppo. L’obiettivo è evitare che repository e cache continuino a rimbalzare tra C: e D:. Più operazioni I/O restano sul volume ottimizzato, maggiore è la possibilità di ottenere un beneficio concreto.

Dove mettere gli output delle compilazioni

Lo stesso principio vale per bin, obj, target, dist e per tutte le directory che contengono file intermedi o risultati delle build.

Se il progetto risiede già in D:\src\progetto, molti strumenti generano automaticamente gli output sullo stesso volume. In alternativa si può usare una directory dedicata, ad esempio D:\build\progetto.

Si tratta di un approccio particolarmente utile con grandi solution Visual Studio, progetti C++, Java, Rust o frontend che generano continuamente molti file temporanei.

Come controllare che tutto sia configurato correttamente

Per verificare lo stato delle Unità di sviluppo si può usare il comando segutente:

fsutil devdrv query

Per controllare invece che D: utilizzi il filesystem ReFS si può usare la cmdlet PowerShell Get-Volume -DriveLetter D oppure il comando fsutil fsinfo volumeinfo D: da una finestra cmd (Prompt dei comandi).

Non è necessario aggiungere manualmente l’intera unità alle esclusioni di Microsoft Defender. Come spiegato in precedenza, sulle Unità di sviluppo attendibili Defender può utilizzare la propria modalità prestazioni, che riduce l’impatto delle scansioni senza rinunciare completamente ai controlli antivirus.