FUSE su Linux: cos'è e perché con Linux 7.4 può correre molto di più

Per oltre vent’anni FUSE ha permesso a Linux di eseguire file system in spazio utente, spostando buona parte della logica fuori dal kernel e rendendo molto più semplice sviluppare soluzioni per storage remoti, file system virtuali e servizi specializzati. Montare via SSH la directory di un server remoto e usarla come se fosse una cartella locale. Accedere a uno spazio cloud attraverso i normali strumenti del file system. Creare un file system cifrato senza scrivere un driver da eseguire nel kernel.

Dietro operazioni di questo tipo, su Linux, c’è spesso proprio FUSE ovvero una tecnologia presente nel kernel che permette di implementare un file system con un normale programma eseguito in spazio utente.

Il divario rispetto ai file system che lavorano direttamente nel kernel si è progressivamente ridotto. Linux 7.3, ad esempio, ha introdotto una serie di ottimizzazioni sul trasporto FUSE; ora il lavoro destinato con ogni probabilità a Linux 7.4 punta a un’altra area molto importante con l’uso dei large folios. I primi test mostrano incrementi consistenti in alcuni carichi di lavoro e aiutano anche a capire quanto sia cambiato FUSE rispetto all’immagine, ormai datata, di soluzione necessariamente lenta perché eseguita in userspace.

Cos’è FUSE e perché esiste

FUSE significa “Filesystem in Userspace“: Linux continua a presentare all’applicazione un normale file system, con directory, file, permessi, chiamate read(), write(), open() e così via, ma la logica che decide cosa restituire e dove recuperare realmente i dati può risiedere in un processo esterno al kernel.

La documentazione ufficiale del kernel Linux descrive FUSE come un framework formato essenzialmente da tre elementi: il modulo kernel fuse.ko, una libreria userspace come libfuse e un’utilità di montaggio quale fusermount. Il componente nel kernel gestisce l’integrazione con VFS, Virtual File System Linux; il daemon in spazio utente implementa invece il comportamento concreto del file system.

Quando un programma prova, ad esempio, ad aprire /mnt/remoto/documento.txt, il kernel non deve necessariamente conoscere il protocollo usato per recuperare quel documento. Può inoltrare la richiesta al processo FUSE attraverso /dev/fuse. Il daemon la interpreta, svolge il lavoro necessario e restituisce la risposta: dietro questo passaggio potrebbero esserci una connessione SSH, un servizio cloud, un archivio cifrato o persino dati generati al volo.

Dove incontriamo FUSE senza accorgercene

Un esempio immediato è SSHFS: invece di trasferire manualmente i file con scp o sftp, SSHFS può esporre una directory remota all’interno dell’albero locale. Per le applicazioni quella directory appare quasi come qualunque altra cartella, mentre il programma userspace converte le operazioni sul file system in richieste SFTP trasportate attraverso SSH.

Un caso simile riguarda rclone mount: servizi di object storage e cloud storage possono apparire sotto una directory locale proprio grazie a FUSE.

Applicazioni come gocryptfs sfruttano invece il meccanismo per creare viste cifrate dei dati. Anche AppImage ha storicamente utilizzato FUSE per montare al volo il file system contenuto in un’immagine applicativa.

Un altro nome noto è NTFS-3G, che per molti anni ha rappresentato la soluzione standard per accedere in lettura e scrittura ai volumi NTFS da Linux usando FUSE. Oggi il kernel dispone anche del driver NTFS3 nativo, quindi i due casi non vanno confusi, ma l’esempio aiuta a capire la portata della tecnologia: un formato di file system complesso può essere supportato senza collocare tutta la sua implementazione all’interno del kernel.

Come si usa FUSE nella pratica

Di norma l’utente non avvia direttamente fuse.ko e non comunica “a mano” con /dev/fuse; lo fa l’applicazione che implementa il file system.

SSHFS offre un esempio concreto: dopo aver installato il relativo pacchetto, si può creare un punto di mount e collegare una directory remota con un comando del tipo:

mkdir ~/server-remoto

sshfs utente@server:/percorso/remoto ~/server-remoto

Da quel momento comandi come ls, cp, cat o un file manager possono operare dentro ~/server-remoto. SSHFS riceve tramite FUSE le richieste del kernel e le traduce nel protocollo necessario per dialogare con la macchina remota. Per smontare un file system FUSE si può utilizzare quanto segue:

fusermount3 -u ~/server-remoto

Cos’è un folio e perché Linux sta abbandonando la logica pagina per pagina

Per capire la novità attesa con Linux 7.4 bisogna scendere di un livello. Linux gestisce la memoria in unità chiamate pagine; sulle comuni macchine x86-64 una pagina base misura normalmente 4 KB.

Il problema appare quando bisogna gestire grandi quantità di dati contigui: un file da 1 MB corrisponde, con pagine da 4 KB, a 256 pagine. Trattarle individualmente significa ripetere numerose operazioni di gestione che possono risultare piuttosto penalizzanti.

Il kernel ha quindi introdotto il concetto di folio: una rappresentazione che permette di trattare insieme una o più pagine fisiche contigue. Un folio non è necessariamente più grande di una pagina, ma un large folio sì. Il vantaggio è intuitivo: se una quantità consistente di dati può essere amministrata come un unico oggetto, il kernel deve manipolare meno strutture e può ridurre parte dell’overhead.

La patch che abilita i large folios per FUSE è entrata nel ramo di sviluppo che ne abilita potenzialmente l’inclusione all’interno del kernel Linux 7.4.

Guadagni importanti, ma non in ogni situazione

La patch applicata a FUSE sembra essere destinata ad assicurare miglioramenti prestazionali davvero notevoli.

Durante i test, letture sequenziali da 1 MB sono passate indicativamente da circa 4,4 a 7,1 GB/s su una macchina e da 3,7 a 6,4 GB/s su un’altra. Un’altra revisione ha introdotto incrementi nell’ordine del 15-20% sulle scritture e guadagni molto elevati nelle letture sequenziali successive alla prima, quando i dati sono già presenti nella page cache.

Numeri del genere non significano che FUSE diviene all’improvviso 8 volte più veloce: una lettura remota attraverso SSHFS, per esempio, può dipendere soprattutto da rete, cifratura e latenza del server. Anche i test sulle letture casuali o sul direct I/O hanno mostrato benefici molto inferiori o assenti.

Tuttavia, quando l’overhead della gestione della memoria e della page cache rappresenta una parte significativa del costo totale, aggregare più pagine in un folio consente al kernel di compiere meno lavoro per trasferire la stessa quantità di dati.

Cosa cambia davvero per chi usa Linux

Per l’utente normale non comparirà una nuova opzione chiamata large folios da attivare prima di montare SSHFS o rclone. Se il supporto entrerà effettivamente in Linux 7.4, saranno il kernel e il sottosistema FUSE a sfruttarlo quando le condizioni lo consentono.

L’effetto potenziale si vedrà soprattutto nei servizi FUSE che muovono grandi quantità di dati e che non sono già limitati da una rete lenta o dallo storage sottostante.

File system userspace appoggiati a SSD NVMe veloci, tmpfs, sistemi di caching, servizi locali e alcune implementazioni orientate ai data center sono candidati molto più credibili a mostrare differenze evidenti rispetto a un semplice mount remoto su una connessione Internet da alcune centinaia di Mbps.