virtiofs

Microsoft ha messo mano a uno dei punti più dolenti di WSL 2, il Sottosistema Windows per Linux, e l'obiettivo è chiaro: rendere più rapido l'accesso ai file condivisi tra i due sistemi. Chi lavora ogni giorno con codice salvato su Windows e strumenti Linux conosce bene il problema. Ogni lettura, ogni scrittura, deve passare attraverso una catena di livelli software e hardware, dall'Hyper-V ai dispositivi virtuali VirtIO fino ai meccanismi DMA, quel sistema che permette il trasferimento diretto dei dati tra memoria e periferiche. Risultato? Un ritardo che si fa sentire. Negli anni l'azienda ha provato diverse strade per limitare questo sovraccarico. Si è passati da DrvFs al protocollo Plan 9, poi è arrivato virtiofs. E adesso un aggiornamento del codice di WSL, finito nel repository pubblico, promette un altro passo avanti grazie a interventi su SWIOTLB, un componente poco conosciuto ma decisivo nel gestire il passaggio dei dati tra memoria e dispositivi. La modifica taglia un collo di bottiglia che riguardava soprattutto i percorsi usati da virtiofs e dalla modalità di rete VirtioProxy, due tecnologie sempre più centrali nell'architettura WSL. Tutto questo arriva mentre il sottosistema Linux dentro Windows si allarga verso scenari sempre più ambiziosi: container nativi, sviluppo software ad alte prestazioni, workload AI accelerati da GPU. Perché virtiofs è diventato così importante WSL 2 fa girare una vera istanza Linux dentro una macchina virtuale Hyper-V leggera. Questo garantisce una compatibilità nettamente superiore rispetto a WSL 1, perché si può usare il kernel Linux originale, i container Docker, strumenti di sviluppo avanzati e tecnologie come Kubernetes senza dover stravolgere nulla. Il nodo, come accennato, resta la condivisione dei file. Tanti sviluppatori tengono il codice sorgente nelle directory di Windows e lo aprono sia dagli strumenti Windows sia dagli ambienti Linux. Ogni operazione, quindi, deve attraversare il livello di virtualizzazione che divide i due mondi. Per spingere sulle prestazioni Microsoft ha man mano sostituito i vecchi meccanismi con virtiofs, una tecnologia pensata proprio per condividere le directory in modo diretto tra host e macchina virtuale. Rispetto al vecchio protocollo Plan 9, la latenza cala in modo sensibile e le operazioni di input/output più pesanti girano meglio. Il ruolo di SWIOTLB e come provare subito l'ottimizzazione La novità appena introdotta tocca un componente del kernel Linux che si chiama SWIOTLB, sigla che sta per Software Input/Output Translation Lookaside Buffer. È un meccanismo che entra in gioco durante le operazioni DMA. Negli ambienti virtualizzati con WSL 2 alcuni dispositivi VirtIO usano dei buffer intermedi gestiti da SWIOTLB per restare compatibili con i meccanismi di accesso alla memoria. Funzionava, certo, ma fino a oggi più dispositivi condividevano lo stesso pool di memoria temporanea. E quando più componenti chiedono di accedere insieme a queste risorse, nascono situazioni di contesa che fanno salire la latenza. La patch firmata dagli sviluppatori Microsoft propone una soluzione semplice ma efficace: ogni dispositivo VirtIO può ora contare su un proprio pool SWIOTLB dedicato, invece di affidarsi a una risorsa condivisa. Meno lock, meno competizioni tra dispositivi diversi. Le richieste generate da virtiofs, per dire, non si scontrano più con le stesse strutture dati usate da altri componenti. Come fare per provarlo subito Per chi vuole metterci subito le mani, la nuova gestione dei pool è già nelle versioni più recenti del kernel di WSL. Basta aggiornare il sottosistema con il comando wsl.exe --update --pre-release da una finestra PowerShell o dal Prompt dei comandi aperti come amministratore. Conviene poi abilitare virtiofs modificando il file .wslconfig nella directory del proprio profilo utente Windows e aggiungendo le righe e virtiofstrue. Dopo aver salvato serve un wsl --shutdown per arrestare tutto e poi riavviare la distribuzione Linux. Attenzione: virtiofs non è ancora attivo di default, senza questa impostazione WSL continua a usare Plan 9 tramite un socket Hyper-V. Un'altra avvertenza riguarda la memoria. La nuova configurazione richiede almeno 64 MB liberi per il pool dedicato, quindi meglio assegnare all'istanza WSL almeno 1 GB di RAM, soprattutto con compilazioni, container o attività che generano molte operazioni di input/output. I benefici, infatti, si vedono proprio nei carichi pesanti: build Node.js piene di piccoli file, immagini Docker, workload basati su container. E il discorso pesa ancora di più ora che Microsoft sta lavorando a wslc, un runtime per far girare container Linux in modo nativo, sfruttando virtiofs per la condivisione dei dati e il supporto GPU per i carichi AI e di machine learning.

virtiofs

WSL 2 più veloce: Microsoft ottimizza l’accesso ai file condivisi