Windows 11 Dev Drive: cos'è e come configurarlo

Windows 11 Dev Drive non è un semplice “disco in più”: è un volume pensato per chi compila spesso, gestisce repository grandi, scarica dipendenze in massa e vuole ridurre il rumore di fondo del file system tradizionale. La differenza pratica è questa: invece di trattare il workspace di sviluppo come una cartella qualunque dentro NTFS, Microsoft ha introdotto un percorso più adatto a carichi con tantissimi file piccoli, operazioni di lettura/scrittura ripetute e scansioni continue da parte degli strumenti di sicurezza.

La logica dietro Dev Drive è semplice: isolare il codice e gli artefatti di build dal resto del profilo utente, applicare un file system più adatto a quel tipo di lavoro e ridurre alcune penalizzazioni che su macchine da sviluppo pesano più che su un PC generico. Il risultato non è magia, ma in molti ambienti si traduce in meno attrito quando l’IDE indicizza, quando il package manager scompatta dipendenze o quando la pipeline locale fa build e test in loop.

Che cos’è davvero un Dev Drive

Dev Drive è un volume dedicato introdotto in Windows 11 per ospitare repository, workspace e altri dati di sviluppo. La scelta tecnica più rilevante è l’uso di ReFS, il Resilient File System, al posto del classico NTFS. ReFS non nasce per sostituire NTFS in ogni scenario: Windows lo usa qui perché offre un modello più adatto a certi pattern di accesso e a certi obiettivi di resilienza dei dati.

Il punto non è “ReFS è più veloce in assoluto”. Il punto è che, per il lavoro da sviluppatore, un volume separato e ottimizzato può ridurre overhead e interferenze. Quando il workspace contiene decine o centinaia di migliaia di file, il costo delle scansioni, dei metadata update e delle operazioni ripetute si sente molto più che su un disco usato per documenti o media.

Un Dev Drive è quindi una scelta di architettura locale, non una semplice comodità. È utile quando vuoi separare:

• codice sorgente;
• cache di build;
• dipendenze scaricate localmente;
• output temporanei di compilazione;
• progetti che vengono toccati di continuo da IDE, agent e toolchain.

Quando ha senso usarlo e quando no

Ha senso se lavori spesso con stack che generano molti file o fanno tante operazioni su file piccoli: .NET, Node.js con repository grandi, Java con build articolate, container image locali, monorepo, toolchain che espandono cache e pacchetti in modo aggressivo. Ha senso anche su laptop e workstation dove vuoi tenere il codice separato dal profilo utente e dal sistema operativo.

Ha meno senso se il tuo uso è sporadico, se lavori quasi solo su pochi file, o se il collo di bottiglia non è il file system ma la CPU, la RAM o la rete. Se la build è lenta perché il progetto è mal configurato o perché l’ambiente è pieno di dipendenze inutili, Dev Drive non risolve il problema alla radice. Migliora il contesto, non la qualità del progetto.

Un errore comune è pensare che Dev Drive sia un acceleratore universale. In realtà è una scelta mirata: utile quando il carico è dominato da I/O e metadata, meno visibile quando il limite è altrove. Se hai un SSD lento, poca RAM o antivirus troppo aggressivo su tutto il disco, il guadagno esiste ma non fa miracoli.

ReFS: perché è il file system dietro Dev Drive

ReFS è stato progettato con un’attenzione diversa rispetto a NTFS. In un contesto Dev Drive conta soprattutto la robustezza su volumi dati e la gestione di strutture complesse con molti file. Windows 11 sfrutta ReFS per rendere il volume più adatto a workload di sviluppo moderni, dove il numero di oggetti e il churn possono essere elevati.

Non significa che ReFS sia “meglio” di NTFS in senso assoluto. NTFS resta il file system di riferimento per gran parte degli scenari Windows, soprattutto quando servono compatibilità estesa, funzioni legacy o integrazioni storiche con software che si aspettano NTFS. Dev Drive sceglie ReFS perché il target è ristretto: volumi dedicati allo sviluppo, non il disco di sistema.

Il vantaggio operativo è che puoi separare il lavoro pesante dal resto del PC. Questo aiuta anche nella manutenzione: se il volume è dedicato, è più facile decidere policy, esclusioni mirate, backup e retention. In pratica smetti di trattare il workspace come “una cartella in C:” e inizi a ragionare per dominio funzionale.

Prerequisiti pratici prima di creare il volume

Prima di configurarlo conviene verificare tre cose: edizione di Windows 11 supportata, disponibilità di spazio su disco o su disco virtuale, e diritti amministrativi. Se stai lavorando su una macchina gestita, conta anche la policy aziendale: alcune configurazioni di sicurezza o di storage possono limitare la creazione di volumi ReFS o il ricorso a determinati backend.

Se il sistema è già sotto pressione, la priorità non è creare Dev Drive ma capire dove sta il collo di bottiglia. Controlla spazio libero, stato SSD, memoria e agent di sicurezza. Il vantaggio di Dev Drive si vede meglio quando il resto dell’ambiente è sano.

Una verifica minima utile, prima di cambiare qualcosa, è osservare il tipo di dischi disponibili e lo spazio residuo. Su Windows puoi partire da PowerShell:

Get-Volume | Select-Object DriveLetter, FileSystemLabel, FileSystem, HealthStatus, SizeRemaining, Size

Se vedi già volumi quasi pieni, conviene risolvere quello prima. Un volume dedicato ma saturo resta un volume lento e fragile.

Come configurarlo da Impostazioni

Il percorso più semplice è il pannello di Windows. In molte installazioni recenti trovi l’opzione dentro le impostazioni di sistema dedicate agli sviluppatori o allo storage. L’idea è creare un nuovo volume o assegnare una partizione libera come Dev Drive, scegliendo dimensione, lettera e file system ReFS. Se la macchina ha già uno spazio non allocato, il flusso è più lineare. Se invece devi ridistribuire un disco esistente, serve più attenzione al rischio.

La sequenza logica è questa:

1. aprire le impostazioni di archiviazione o di sviluppo;
2. selezionare la creazione di un Dev Drive;
3. scegliere lo spazio da usare;
4. impostare nome e lettera del volume;
5. completare la formattazione su ReFS;
6. spostare dentro il workspace o creare il nuovo repository direttamente lì.

Il vantaggio del pannello è che riduce gli errori operativi. Se stai preparando una workstation per sviluppo, è la via più pulita per l’uso manuale. Se invece devi standardizzare più macchine, conviene documentare il processo e, dove possibile, automatizzare con script o provisioning.

Quando il wizard chiede conferma, fermati un momento: la formattazione cancella i dati presenti sul volume scelto. Se il disco non è vuoto, fai prima un backup o un migrazione controllata. Non c’è nessun motivo per rischiare codice o cache importanti per una configurazione che puoi fare in sicurezza con un passaggio in più.

Creazione con PowerShell: quando serve controllo preciso

Se vuoi una procedura più ripetibile, PowerShell è la strada più utile. Non perché sia “più avanzata”, ma perché ti lascia controllare meglio il flusso e verificare ciò che succede. Prima però va chiarito un punto: i comandi esatti possono variare in base alla build di Windows 11 e agli aggiornamenti installati. Se il cmdlet non esiste o il comportamento non coincide, va verificata la documentazione del sistema con `Get-Command` e la guida locale.

Una verifica iniziale utile è questa:

Get-Command *DevDrive*

Se compaiono cmdlet dedicati, puoi usarli. Se non compaiono, il sistema potrebbe richiedere un percorso da interfaccia o un altro metodo supportato dalla tua build. In quel caso il gap non va inventato: va chiuso controllando la versione di Windows, le feature disponibili e la documentazione Microsoft della release installata.

Un approccio prudente, quando lavori su storage, è sempre partire dal riconoscimento del disco e dalla situazione corrente:

Get-Disk | Select-Object Number, FriendlyName, OperationalStatus, Size, PartitionStyle

Da lì puoi decidere se usare spazio non allocato, un disco secondario o un VHD dedicato. Su macchine di sviluppo spesso un disco secondario fisico o un VHD ben dimensionato è la soluzione più pulita: separi il workload, limiti l’impatto sul sistema e semplifichi il rollback.

Come spostare il workspace senza farsi male

Il punto più delicato non è creare il volume, ma migrare i dati senza rompere riferimenti, percorsi o toolchain. Se il repository è gestito da Git, la migrazione è semplice: cloni o sposti il working tree e aggiorni i path nell’IDE. Se invece hai build cache, symlink, percorsi hardcoded o strumenti che si aspettano una posizione precisa, serve più disciplina.

La regola pratica è: sposta prima il codice, poi le cache, infine gli artefatti temporanei. Non fare il contrario. Se qualcosa va storto, il codice resta accessibile e il rollback è più semplice. Per evitare sorprese, conviene verificare subito che il nuovo percorso sia visto correttamente dai tool principali.

Per esempio, dopo aver spostato un repository, controlla:

git status

e poi lancia un’operazione che tocca il file system in modo reale, come una build o un test rapido. Se l’IDE continua a puntare al vecchio path, il problema non è Dev Drive ma la configurazione del progetto o della workspace list.

Impatto su antivirus e indicizzazione

Uno dei motivi per cui Dev Drive viene percepito come utile è il rapporto con gli strumenti di sicurezza e indicizzazione. I workspace di sviluppo vengono visitati in continuazione da scanner, watcher e motori di ricerca locale. Su repository grandi, questo traffico può diventare più costoso della build stessa.

Qui serve attenzione: non si disattiva la sicurezza “per andare più veloci”. Si ragiona per esclusioni mirate e per policy ragionevoli. Se il tuo antivirus supporta eccezioni per il Dev Drive o per i percorsi di sviluppo, valuta l’impatto in modo circoscritto. L’obiettivo è ridurre la scansione ridondante sul materiale di lavoro, non aprire una porta inutile sul sistema.

La verifica da fare è semplice: prima e dopo la configurazione osserva tempi di apertura del progetto, durata di una build pulita e latenza percepita dell’IDE. Se i tempi migliorano solo marginalmente, il problema è probabilmente altrove. Se invece l’indicizzazione o la scansione erano il collo di bottiglia, il guadagno si vede abbastanza in fretta.

Back-up, recovery e separazione dei ruoli

Un Dev Drive va pensato anche come unità amministrativa, non solo come spazio tecnico. Essendo dedicato allo sviluppo, può avere policy di backup diverse rispetto al resto del PC. È una buona idea distinguere tra dati rigenerabili e dati non rigenerabili:

• rigenerabili: build output, cache, package reinstallabili;
• non rigenerabili: codice non versionato, chiavi di test, configurazioni locali, database di sviluppo con stato utile.

Questa distinzione evita errori banali. Non tutto ciò che sta nel workspace merita backup uguale. Anzi, fare backup indiscriminati di cache e dipendenze può aumentare tempi e complessità senza aggiungere valore. Meglio salvare il codice, le configurazioni critiche e gli eventuali dati di test che non puoi ricostruire facilmente.

Se usi un VHD o un disco secondario come base del Dev Drive, il rollback è più semplice: puoi smontare, ripristinare da snapshot o ricreare il volume. Il blast radius resta limitato al workspace, non all’intero sistema.

Problemi tipici e come riconoscerli

Il primo problema è banale: il volume non compare o non è disponibile. In quel caso controlla stato disco, lettera assegnata e spazio libero. Il secondo è più subdolo: il Dev Drive esiste, ma gli strumenti continuano a lavorare sul vecchio path. Qui il comando utile è verificare variabili d’ambiente, configurazioni dell’IDE e path dei task di build.

Il terzo problema è la compatibilità applicativa. Alcuni tool vecchi o molto specifici possono aspettarsi NTFS e comportarsi male con ReFS. In quel caso non forzare il passaggio: isola quel tool su un volume NTFS e tieni Dev Drive per il resto del lavoro. L’architettura giusta non è “tutto su Dev Drive”, ma “Dev Drive dove porta vantaggio reale”.

Se vuoi una conferma rapida che il volume sia stato creato correttamente, controlla il file system e lo stato del volume:

Get-Volume -DriveLetter D | Format-List DriveLetter, FileSystem, HealthStatus, SizeRemaining

Il risultato atteso è ReFS e uno stato sano. Se il file system non è quello atteso, c’è stato un errore di creazione o di assegnazione, e va rivisto il flusso prima di usarlo in produzione locale.

Dev Drive in una workstation ben progettata

La configurazione più sensata non è isolare tutto su Dev Drive, ma usarlo come strato specializzato dentro una workstation ordinata. Il sistema operativo resta sul disco principale, i dati personali dove già stanno, e il lavoro di sviluppo sul volume dedicato. In questo modo il PC è più leggibile anche da chi lo amministra dopo di te.

Se devi standardizzare una postazione per team interni, la scelta migliore è documentare tre cose: dove risiede il codice, dove finiscono cache e artefatti, e come si ripristina il volume se qualcosa va storto. Questa è la parte che spesso manca nei setup improvvisati: non il volume in sé, ma il criterio con cui lo usi.

Un Dev Drive funziona bene quando è inserito in una disciplina più ampia: repository puliti, dipendenze riproducibili, build script consistenti, backup selettivi e osservabilità minima sul comportamento della macchina. Se l’ambiente è disordinato, il volume dedicato può migliorare la situazione ma non la governa.

Decisione pratica finale

Se fai sviluppo su Windows 11 in modo regolare, Dev Drive vale la pena almeno da valutare. È particolarmente sensato quando il tuo lavoro produce molti file, quando l’IDE è sempre in ascolto e quando vuoi separare il workspace dal resto della macchina. Se invece lavori in modo sporadico o su progetti piccoli, può restare una buona opzione ma non una priorità.

La domanda giusta non è “posso attivarlo?”. La domanda giusta è “mi aiuta a ridurre attrito concreto su questo workstation?”. Se la risposta è sì, la configurazione è sensata. Se la risposta è no, meglio tenere la macchina semplice e investire tempo altrove: build più pulite, meno dipendenze inutili, storage più veloce o più RAM.

Assunzione: le procedure operative possono variare leggermente in base alla build di Windows 11 e alle feature installate; prima di automatizzare, verifica i cmdlet disponibili con `Get-Command *DevDrive*` e lo stato dei volumi con `Get-Volume`.