Mengapa server Linux NFS diimplementasikan di kernel sebagai lawan dari userspace?

Saya hanya ingin tahu mengapa server Linux NFS diimplementasikan di kernel sebagai lawan dari aplikasi userspace?

Saya tahu daemon userspace NFS ada, tetapi itu bukan metode standar untuk menyediakan layanan server NFS.

Saya akan berpikir bahwa menjalankan server NFS sebagai aplikasi userspace akan menjadi pendekatan yang disukai karena dapat memberikan keamanan tambahan dengan menjalankan daemon di userspace alih-alih kernel. Itu juga akan cocok dengan prinsip umum Linux untuk melakukan satu hal dan melakukannya dengan baik (dan daemon itu seharusnya tidak menjadi pekerjaan untuk kernel).
Kenyataannya satu-satunya keuntungan yang dapat saya pikirkan untuk berjalan di kernel adalah peningkatan kinerja dari pengalihan konteks (dan itu adalah alasan yang bisa diperdebatkan).

Jadi adakah alasan yang terdokumentasi mengapa ini diterapkan seperti itu? Saya mencoba mencari-cari tetapi tidak menemukan apa pun.

Tampaknya ada banyak kebingungan, harap dicatat saya tidak bertanya tentang pemasangan sistem file, saya bertanya tentang menyediakan sisi server dari sistem file jaringan . Ada perbedaan yang sangat berbeda. Mount sistem file secara lokal memerlukan dukungan untuk sistem file di kernel, asalkan tidak (mis. Samba atau unfs3).

linux kernel nfs

— Patrick
sumber

NFS adalah sistem file. Driver filesystem Userspace harus menggunakan FUSE, yang biasanya buruk untuk kinerja.

— jordanm

@jordanm tidak, mereka tidak. Bahkan Anda tidak dapat menjalankan sistem file jaringan (NFS, CIFS / samba, coda, dll) melalui FUSE. FUSE dimaksudkan untuk memasang sistem file pada mesin lokal, bukan melayani mereka.

— Patrick

Anda benar, pernyataan saya hanya akan berlaku untuk klien.

— jordanm

@jordanm bahkan tidak seburuk itu. Anda dapat memasang sistem file tanpa FUSE. FUSE adalah teknologi yang relatif baru, sisi klien dari sistem file jaringan sudah ada jauh sebelum FUSE :-). FUSE hanya menyediakan cara untuk mendukung sistem file yang tidak disediakan oleh kernel (tidak berusaha menjadi kejam, hanya berharap untuk menjernihkan kesalahpahaman :-P)

— Patrick

@StarNamer Anda masih berbicara tentang klien. Saya berbicara tentang server. Anda dapat menjalankan unfs3(yang merupakan server NFS) tanpa dukungan kernel untuk itu.

— Patrick

Jawaban:

unfs3sudah mati sejauh yang saya tahu; Ganesha adalah proyek server NFS userspace paling aktif saat ini, meskipun belum sepenuhnya matang.

Meskipun melayani protokol yang berbeda, Samba adalah contoh server file yang berhasil yang beroperasi di userspace.

Saya belum melihat perbandingan kinerja terbaru.

Beberapa masalah lain:

Aplikasi biasa mencari file berdasarkan pathname, tetapi nfsdharus dapat mencarinya dengan filehandle. Ini rumit dan memerlukan dukungan dari sistem file (dan tidak semua sistem file dapat mendukungnya). Di masa lalu tidak mungkin melakukan ini dari userspace, tetapi kernel yang lebih baru telah ditambahkan name_to_handle_at(2)dan open_by_handle_at(2)panggilan sistem.
Sepertinya saya ingat memblokir panggilan penguncian file menjadi masalah; Saya tidak yakin bagaimana server userspace menangani mereka hari ini. (Apakah Anda mengikat utas server menunggu di kunci, atau apakah Anda polling?)
Semantik sistem file yang lebih baru (mengubah atribut, delegasi, kunci berbagi) dapat diimplementasikan lebih mudah di kernel terlebih dahulu (secara teori - mereka kebanyakan belum).
Anda tidak ingin harus memeriksa izin, kuota, dll., Dengan tangan - alih-alih Anda ingin mengubah uid dan bergantung pada kode vfs kernel umum untuk melakukan itu. Dan Linux memiliki system call ( setfsuid(2)) yang harus melakukan itu. Untuk alasan yang saya lupa, saya pikir itu terbukti lebih rumit untuk digunakan di server daripada yang seharusnya.

Secara umum, kekuatan server kernel adalah integrasi yang lebih dekat dengan vfs dan sistem file yang diekspor. Kita dapat menebusnya dengan menyediakan lebih banyak antarmuka kernel (seperti panggilan sistem filehandle), tetapi itu tidak mudah. Di sisi lain, beberapa sistem file yang orang ingin ekspor hari ini (seperti gluster) sebenarnya hidup terutama di userspace. Itu dapat diekspor oleh kernel nfsd menggunakan FUSE - tetapi sekali lagi ekstensi ke antarmuka FUSE mungkin diperlukan untuk fitur yang lebih baru, dan mungkin ada masalah kinerja.

Versi singkat: pertanyaan bagus!

— J. Bruce Fields
sumber

Pembaca harus mencatat bahwa Bruce adalah (a? The?) Server dari server linux NFS, jadi mungkin dia tahu apa yang dia bicarakan. :)

— Dan Pritts

@derfian FYI - Anda mungkin ingin berkomentar di sini untuk efek " unfs3masih hidup dan pindah ke Github" ?

— ms-ati

Saya berkomentar di atas karena @derfian, atau pengguna StackOverflow ( unix.stackexchange.com/users/23034/derfian ), adalah pengelola unfs3, dan baru-baru ini mengumumkan bahwa itu tidak mati, misalnya dalam komentar Github ini

— ms-ati

Untuk ditulis oleh pengelola NFS, jawaban ini cukup kabur.

— Torsten Bronger

Olaf Kirch awalnya mengembangkan ruang pengguna dan versi berbasis server NFS. Dalam bukunya tahun 2000, "Linux Network Administration" katanya:

Kernel 2.2.0 mendukung server NFS berbasis kernel eksperimental yang dikembangkan oleh Olaf Kirch dan dikembangkan lebih lanjut oleh HJ Lu, G. Allan Morris, dan Trond Myklebust. Dukungan NFS berbasis kernel memberikan dorongan signifikan dalam kinerja server.

Saya pikir begitu server NFS dipindahkan ke kernel untuk meningkatkan kinerja, tidak ada yang melihat alasan untuk mengeluarkannya lagi.

— StarNamer
sumber

Starnamer benar (saya adalah salah satu penguji beta).

Menempatkannya di kernel adalah upaya untuk meningkatkan kinerja buruk (terutama untuk klien PCNFS) dan sekali masalah itu diselesaikan, tidak ada yang melihatnya lagi.

Ada sejumlah kekurangan dengan memiliki NFS di kernel, yang paling penting adalah bahwa ia tidak bermain dengan baik dengan apa pun yang menyentuh sistem file yang sama (ada risiko korupsi yang sangat buruk) tetapi saat itu (1993-4) kami tidak tidak menyadari bahwa itu akan menjadi masalah.

Kami lebih muda dan lebih bodoh, dll.

— stoatwblr
sumber