Ci sono due aspetti di questa domanda: perché uno vorrebbe sviluppare un'interfaccia per filesystem per i dati, e l'altro, perché uno vorrebbe farlo nello userspace?
Rispondiamo prima alla seconda, perché è ovvia: perché è waaaaayyyyy più facile. In realtà, la domanda dovrebbe essere posta al contrario: perché si vorrebbe implementare un filesystem nel kernel? Perché si vorrebbe implementare qualcosa nel kernel, davvero? E la risposta è: tu non vuoi implementare qualcosa nel kernel. Lo fai, perché hai , perché non puoi implementarlo in altro modo. Bene, in questo caso, puoi , e così fai.
Il primo è un po 'più complicato: perché vogliamo avere un'interfaccia del filesystem per i dati? E la risposta è: perché c'è una grande quantità di strumenti che possono funzionare con i file, quindi esponendo i dati come file, si ottiene l'accesso a tutti questi strumenti.
Immagina per esempio un filesystem di metadati, che espone i metadati dei file come file all'interno di una cartella. Quindi, un file MP3 o JPEG apparirebbe come cartelle e potresti cd in un file MP3 e all'interno di quella cartella, ci sarebbero file come artist.txt , title.txt , album.txt , lyrics.txt , ecc. Ora, se volessi modificare in massa i titoli dei tuoi file MP3, non avresti bisogno di usare un editor di tag che qualcun altro ha scritto, che potrebbe non avere la caratteristica che ti serve, potresti semplicemente usare tutti gli strumenti per modificare il testo i file con cui hai familiarità - e la modifica dei file di testo è qualcosa che abbiamo sempre fatto fin dagli albori dell'informatica, quindi siamo molto bravi in questo! (O allo stesso modo, elimina tutte le informazioni dell'autore da tutti i documenti di Word sul tuo sistema, sarebbe assolutamente banale!)
Oppure, immagina un gitfs, che espone rami, tag, commit, ecc. come cartelle, ed è possibile esplorare la cronologia usando gli stessi strumenti che già sai come usare per esplorare il tuo filesystem. Oppure, un mediaconvertfs, che espone tutti i tuoi file audio, indipendentemente dal formato in cui sono effettivamente , come file MP3 e li converte al volo. Un firefoxfs che espone la cronologia di navigazione di Firefox o le impostazioni come una gerarchia di cartelle. Un filesystem in grado di montare Google Drive, Dropbox, iCloud, OneDrive, ecc. Come una gerarchia di cartelle. Un gmailfs che può montare le tue email come una gerarchia di cartelle. Un wordpressfs che ti consente di modificare il tuo blog come una gerarchia di cartelle. E così via.
Si noti che qualcosa di simile sta già accadendo nel mondo Windows. Ad esempio, PowerShell ha "cmdlet" molto generici che funzionano con tutti i tipi di oggetti, e file e cartelle sono solo un altro tipo di oggetto. Tuttavia, ciò richiede la scrittura di tutti i nuovi cmdlet che possono funzionare con tali oggetti generici e funziona solo in PowerShell. L'approccio di un filesystem userspace è duplice: invece di trattare i file come semplici oggetti e scrivere cmdlet che trattano gli oggetti, si trattano gli oggetti come semplici file e si basano sulla grande quantità di strumenti che sono già stati scritti per trattare con i file. Allo stesso modo, l'esploratore di Windows tenta in alcuni casi di fingere che qualcosa sia una gerarchia di cartelle quando in realtà non lo è, e ti permette di navigare in quel modo. Ma funziona solo con Explorer, non funziona da nessun'altra parte, mentre l'esposizione di qualcosa come un filesystem funziona ovunque, perché tutto sa come gestire i file.
Un'altra cosa diversa che puoi fare con un filesystem di userspace è implementare rapidamente altri filesystem attuali . Ricorda, scrivere codice del kernel è più difficile della scrittura del codice dello spazio utente. Quindi, è spesso più veloce implementare un filesystem nello userspace che nel kernel. Nel mondo Linux, ad esempio, esisteva un'implementazione molto intelligente di NTFS usando un filesystem userspace: era implementato come un livello di compatibilità che emula il kernel NT, e quindi usava semplicemente actual ntfs.sys file da Windows! Lo svantaggio è che questo è un po 'lento e richiede di possedere una licenza Windows (per copiare ntfs.sys da), ma il vantaggio è che per definizione è sempre corretto! Quanto puoi essere più compatibile rispetto all'usare il codice del driver di file effettivo di Microsoft stesso?
Potresti fare qualcosa di simile nel contrario. Per esempio. e2fsprogs contiene libext2fs che è un'implementazione userspace della famiglia di filesystem ext2 / 3/4. Questa libreria è già utilizzata da diversi strumenti di Ext2 per Windows, ma tali strumenti sono solitamente gestori di file unici che consentono di copiare file da e sul filesystem ma non molto altro. Non dovrebbe essere troppo difficile creare un driver di filesystem "appropriato" per lo spazio utente attorno ad esso, per montare senza problemi i filesystem ext2 / 3/4 nello stesso modo in cui è possibile montare i filesystem NTFS e FAT oggi.