Una novità tecnica, sì, ma con ricadute molto concrete per chi lavora su Windows 11 con ambienti Linux virtualizzati e da tempo si scontra con rallentamenti in lettura e scrittura. Il punto è il modo in cui i dispositivi virtuali gestiscono i passaggi di memoria nelle operazioni di I/O. Meno attese, meno conflitti interni. E, nei piani di Redmond, un’esperienza più fluida per chi compila codice, usa container o lavora su carichi legati all’AI.
File condivisi tra Windows e Linux: dov’era il collo di bottiglia
Chi usa WSL 2 tutti i giorni lo sa bene: quando un’app Linux deve leggere o scrivere file salvati nel file system di Windows, il percorso non è semplice come su una macchina Linux tradizionale. I dati passano attraverso più livelli: la macchina virtuale leggera basata su Hyper-V, i dispositivi VirtIO, i meccanismi con cui il kernel gestisce l’accesso alla memoria. Il risultato è che anche un comando banale su una cartella condivisa può portarsi dietro un costo in più.
Quasi invisibile nelle operazioni normali, molto più chiaro quando ci sono di mezzo migliaia di piccoli file. Succede, per esempio, con un progetto Node.js pieno di dipendenze, con una build C++ pesante o con un repository Git aperto sia da Visual Studio Code su Windows sia dagli strumenti Linux nella shell. Non a caso, nei forum tecnici e nelle issue pubbliche di Microsoft, molti sviluppatori hanno spesso consigliato di tenere il codice direttamente nel file system Linux di WSL. Funziona. Ma non è sempre la scelta più comoda per chi si muove di continuo tra i due ambienti.
Da Plan 9 a virtiofs: WSL 2 cambia strada
Negli anni Microsoft ha ritoccato più volte l’architettura del Sottosistema Windows per Linux per accorciare le distanze tra host Windows e guest Linux. All’inizio c’era DrvFs.
Poi è arrivato il protocollo Plan 9, usato per esporre al lato Linux le cartelle di Windows tramite un socket Hyper-V. Una soluzione utile, ma non senza limiti, soprattutto quando le operazioni di input/output diventavano intense. La direzione più recente è virtiofs, una tecnologia nata proprio per condividere cartelle tra host e macchine virtuali con meno latenza rispetto ai sistemi precedenti. In WSL 2, virtiofs permette alla distribuzione Linux di accedere ai file Windows con un percorso più snello, alleggerendo il peso della virtualizzazione.
Non è ancora attivo di default in tutte le configurazioni: per abilitarlo, gli utenti possono modificare il file .wslconfig nel profilo Windows, aggiungendo virtiofs=true nella sezione [wsl2], e poi riavviare il sottosistema con wsl --shutdown. La scelta non arriva per caso. WSL 2 non serve più solo ad aprire Bash su Windows: oggi viene usato per sviluppo web, container, automazione, ambienti Kubernetes locali e test di machine learning. Il messaggio che arriva dagli aggiornamenti tecnici di Microsoft è chiaro: per i carichi moderni serve una base più stabile. In altre parole, il file system non può restare l’anello debole.
SWIOTLB, la patch che riduce le attese dei dispositivi VirtIO
La modifica più recente riguarda SWIOTLB, cioè Software Input/Output Translation Lookaside Buffer, un componente del kernel Linux che entra in gioco nei trasferimenti DMA, i passaggi diretti di dati tra memoria e dispositivi. In ambienti virtualizzati come WSL 2, alcuni dispositivi VirtIO usano buffer intermedi per garantire compatibilità e sicurezza nell’accesso alla memoria. Fin qui, tutto normale. Il problema era un altro: quelle risorse temporanee venivano condivise.
Prima della patch, più dispositivi virtuali potevano appoggiarsi allo stesso pool SWIOTLB, creando rallentamenti quando le richieste arrivavano insieme. Una richiesta generata da virtiofs, magari durante la lettura di molti file, poteva finire in coda insieme ad altri componenti della macchina virtuale. Da qui l’aumento della latenza, soprattutto nelle operazioni ripetute e nei carichi più pesanti.
Con l’aggiornamento inserito nel repository pubblico di WSL, ogni dispositivo VirtIO può ora avere un pool SWIOTLB dedicato. Il concetto è semplice: meno condivisione obbligata, meno lock, meno attese tra componenti diversi. Per provarla sulle versioni più recenti del sottosistema, Microsoft indica l’aggiornamento con wsl.exe --update --pre-release, da lanciare in PowerShell o nel Prompt dei comandi con privilegi di amministratore. Serve anche abbastanza memoria: per i pool dedicati viene indicata una disponibilità di almeno 64 MB, mentre per un uso realistico di WSL è consigliabile assegnare almeno 1 GB di RAM.
Compilazioni, Docker e AI con GPU: dove si vedrà la differenza
Gli effetti della nuova gestione dovrebbero farsi sentire soprattutto nelle attività che moltiplicano gli accessi al file system. Le compilazioni di progetti grandi, le installazioni di pacchetti con migliaia di file, le immagini Docker e i flussi di lavoro basati su container sono i primi casi in cui il cambiamento può pesare. Non è una funzione che si vede con un nuovo pulsante o una nuova voce nell’interfaccia. È uno di quei miglioramenti di base che si notano solo quando funzionano: certe operazioni finiscono prima, il sistema rallenta meno, la shell risponde con più regolarità.
Il tema conta anche per il futuro di WSL 2. Microsoft sta lavorando a scenari in cui il sottosistema Linux diventa una base più solida per container nativi, runtime dedicati e carichi AI con GPU, dove la velocità nel passaggio tra dati, storage e accelerazione grafica può incidere su tutta la catena di lavoro. In questo quadro, virtiofs e i pool dedicati SWIOTLB non sono dettagli per addetti ai lavori: sono pezzi della stessa strategia, avvicinare l’esperienza Linux su Windows a quella di un ambiente nativo, senza costringere gli sviluppatori a scegliere ogni volta tra comodità e prestazioni.
