Perché il server Linux NFS è implementato nel kernel rispetto allo spazio utente?

Mi stavo solo chiedendo perché il server Linux NFS è implementato nel kernel invece di un'applicazione per lo spazio utente?

So che esiste un demone NFS spazio utente , ma non è il metodo standard per fornire servizi server NFS.

Penserei che l'esecuzione del server NFS come applicazione per lo spazio utente sarebbe l'approccio preferito in quanto può fornire maggiore sicurezza facendo funzionare un demone nello spazio utente anziché nel kernel. Si adatterebbe anche al comune principio Linux di fare una cosa e farlo bene (e che i demoni non dovrebbero essere un lavoro per il kernel).
In effetti, l'unico vantaggio che posso pensare di eseguire nel kernel sarebbe un aumento delle prestazioni dal cambio di contesto (e questo è un motivo discutibile).

Quindi c'è qualche motivo documentato per cui è implementato così com'è? Ho provato a cercare su Google ma non sono riuscito a trovare nulla.

Sembra che ci sia molta confusione, si prega di notare che non sto chiedendo di montare filesystem, sto chiedendo di fornire il lato server di un filesystem di rete . C'è una differenza ben distinta. Il montaggio locale di un filesystem richiede il supporto per il filesystem nel kernel, a condizione che non lo faccia (es. Samba o unfs3).

linux kernel nfs

— Patrick
fonte

NFS è un filesystem. I driver del filesystem dello spazio utente devono utilizzare FUSE, che in genere è scarso per le prestazioni.

— Giordania,

@jordanm no non lo fanno. In effetti non è possibile eseguire file system di rete (NFS, CIFS / samba, coda, ecc.) Tramite FUSE. FUSE è pensato per montare filesystem sul computer locale, non servendoli.

— Patrick,

hai ragione, la mia dichiarazione si applicherebbe solo al cliente.

— Giordania,

@jordanm neanche quello purtroppo. Puoi montare filesystem senza FUSE. FUSE è comunque una tecnologia relativamente nuova, il lato client dei filesystem di rete esisteva molto prima di FUSE :-). FUSE fornisce solo un modo per supportare i filesystem non forniti dal kernel (non cercando di essere cattivo, sperando solo di chiarire idee sbagliate :-P)

— Patrick

@StarNamer stai ancora parlando del client. Sto parlando del server. È possibile eseguire unfs3(che è un server NFS) senza alcun supporto del kernel per esso.

— Patrick,

Risposte:

unfs3è morto per quanto ne so; Ganesha è il progetto server NFS per spazio utente più attivo in questo momento, anche se non è completamente maturo.

Sebbene funzioni con protocolli diversi, Samba è un esempio di file server di successo che opera nello spazio utenti.

Non ho visto un recente confronto delle prestazioni.

Alcuni altri problemi:

Le applicazioni ordinarie cercano i file in base al nome percorso, ma nfsddevono essere in grado di cercarli tramite filehandle. Questo è difficile e richiede supporto dal filesystem (e non tutti i filesystem possono supportarlo). In passato non era possibile farlo dallo spazio utente, ma sono stati aggiunti kernel più recenti name_to_handle_at(2)e open_by_handle_at(2)chiamate di sistema.
Mi sembra di ricordare che il blocco delle chiamate con blocco dei file sia un problema; Non sono sicuro di come i server userspace li gestiscano in questi giorni. (Leghi un thread del server in attesa sul blocco o esegui il polling?)
La semantica del file system più recente (modifica attributi, deleghe, blocchi di condivisione) può essere implementata più facilmente nel kernel prima (in teoria - per lo più non lo sono ancora).
Non devi controllare manualmente permessi, quote, ecc., Invece vuoi cambiare il tuo uid e fare affidamento sul codice vfs del kernel comune per farlo. E Linux ha una chiamata di sistema ( setfsuid(2)) che dovrebbe farlo. Per ragioni che dimentico, penso che sia stato più complicato da usare nei server di quanto dovrebbe essere.

In generale, i punti di forza di un server kernel sono l'integrazione più stretta con vfs e il filesystem esportato. Possiamo rimediare fornendo più interfacce del kernel (come le chiamate di sistema di filehandle), ma non è facile. D'altra parte, alcuni dei filesystem che le persone vogliono esportare in questi giorni (come il gluster) in realtà vivono principalmente nello spazio utente. Questi possono essere esportati dal kernel nfsd usando FUSE - ma per le nuove funzionalità potrebbero essere necessarie estensioni alle interfacce FUSE e potrebbero esserci problemi di prestazioni.

Versione breve: buona domanda!

— J. Bruce Fields
fonte

I lettori dovrebbero notare che Bruce è (un? The?) Manutentore del server NFS di Linux, quindi presumibilmente sa di cosa sta parlando. :)

— Dan Pritts,

@derfian FYI - potresti voler commentare qui l'effetto che " unfs3è vivo e si trasferisce su Github" ?

— ms-ati,

Ho commentato quanto sopra perché @derfian, o utente StackOverflow ( unix.stackexchange.com/users/23034/derfian ), è il manutentore di unfs3, e recentemente ha annunciato che non era morto, ad esempio in questo commento di Github

— ms-ati

Per scritto da un manutentore NFS, questa risposta è piuttosto vaga.

— Torsten Bronger,

Olaf Kirch ha originariamente sviluppato sia lo spazio utente sia la versione basata su kernel del server NFS. Nel suo libro del 2000, "Linux Network Administration" afferma:

Il kernel 2.2.0 supporta un server NFS sperimentale basato su kernel sviluppato da Olaf Kirch e ulteriormente sviluppato da HJ Lu, G. Allan Morris e Trond Myklebust. Il supporto NFS basato sul kernel fornisce un significativo aumento delle prestazioni del server.

Penso che una volta che il server NFS è stato spostato nel kernel per migliorare le prestazioni, nessuno ha visto alcun motivo per toglierlo di nuovo.

— StarNamer
fonte

Starnamer è corretto (ero uno dei beta tester).

Inserirlo nel kernel è stato un tentativo di migliorare le prestazioni abissali (principalmente per i client PCNFS) e una volta risolto il problema nessuno lo ha esaminato molto.

Ci sono una serie di carenze nell'avere NFS nel kernel, non ultimo il fatto che non gioca bene con qualcos'altro che tocca lo stesso filesystem (ci sono seri rischi di corruzione) ma allora (1993-4) non lo facevamo ti rendi conto che sarebbe diventato un problema.

Eravamo più giovani e più sciocchi, ecc. Ecc.

— stoatwblr
fonte