Neden Linux NFS sunucusu çekirdeğe kullanıcı alanının aksine uygulanmaktadır?

Neden Linux NFS sunucusunun bir kullanıcı alanı uygulamasının aksine çekirdeğe uygulandığını merak ediyordum?

Bir kullanıcı alanı NFS arka plan programı olduğunu biliyorum , ancak NFS sunucu hizmetleri sağlamak için standart yöntem değil.

NFS sunucusunu bir kullanıcı alanı uygulaması olarak çalıştırmanın, çekirdek yerine kullanıcı alanında çalışan bir servise sahip olması için ek güvenlik sağlayabildiğinden tercih edilen bir yaklaşım olacağını düşünüyorum. Ayrıca, bir şeyi yapmanın ve iyi yapmanın ortak Linux sorumlusuna uyacaktı (ve bu şeytanların çekirdek için bir iş olmaması gerekir).
Aslında, çekirdekte çalıştırmayı düşünebildiğim tek yarar, bağlam anahtarlamadan (ve bu tartışılabilir bir sebep) performans artışı olacaktır.

Öyleyse, uygulandığı şekliyle uygulanmasının belgelenmiş bir nedeni var mı? Etrafta dolaşmayı denedim ama hiçbir şey bulamadım.

unfs3bildiğim kadarıyla öldü; Ganesha şu anda tamamen aktif olmasa da, şu anda en aktif kullanıcı alanı NFS sunucu projesi.

Farklı protokollere hizmet etmesine rağmen Samba, kullanıcı alanında çalışan başarılı bir dosya sunucusuna bir örnektir.

Yeni bir performans karşılaştırması görmedim.

Diğer bazı konular:

• Sıradan uygulamalar, dosyaları yol adlarına göre arar, ancak dosyaları nfsddosyahanesine göre arayabilmeleri gerekir. Bu karmaşık ve dosya sisteminden destek gerektiriyor (ve tüm dosya sistemleri destekleyemez). Geçmişte bunu kullanıcı alanından yapmak mümkün değildi, ancak daha yeni çekirdekler eklendi name_to_handle_at(2)ve open_by_handle_at(2)sistem çağrıları yaptı.
• Dosya kilitleme aramalarını engellemenin sorun olduğunu hatırlıyor gibiyim; Kullanıcı alanı sunucularının bugünlerde onları nasıl idare ettiğini bilmiyorum. (Kilitte bekleyen bir sunucu ipliği mi bağlıyorsunuz, yoksa anket mi yapıyorsunuz?)
• Daha yeni dosya sistemi semantikleri (özellikleri değiştir, delegasyonları, paylaşım kilitlerini değiştir) ilk önce çekirdekte daha kolay uygulanabilir (teoride - çoğunlukla henüz yapılmamıştır).
• Elle izinleri, kotaları vb. Kontrol etmek istemezsiniz - bunun yerine kimliğinizi değiştirmek ve bunun için ortak çekirdek vfs koduna güvenmek istersiniz. Ve Linux'un setfsuid(2)bunu yapması gereken bir sistem çağrısı ( ) vardır. Unuttuğum nedenlerden dolayı, sunucularda olması gerektiğinden daha karmaşık olduğunu kanıtladım.

Genel olarak, bir çekirdek sunucunun güçlü yönleri, vfs ve dışa aktarılan dosya sistemi ile daha yakın bütünleşmedir. Bunu daha fazla çekirdek arayüzü (örneğin dosya sistemi çağırır) sağlayarak telafi edebiliriz, ancak bu kolay değil. Öte yandan, bu günlerde (kızak gibi) vermek istedikleri dosya sistemlerinden bazıları aslında kullanıcı alanında yaşıyor. Bunlar FUSE kullanılarak çekirdek nfsd tarafından dışa aktarılabilir - ancak yine de yeni özellikler için FUSE arayüzlerine uzantılar gerekebilir ve performans sorunları olabilir.

Kısa versiyon: güzel soru!

Olaf Kirch, NFS sunucusunun hem kullanıcı alanını hem de çekirdek tabanlı sürümünü geliştirdi. 2000 yılında "Linux Ağ Yönetimi" adlı kitabında şöyle diyor:

2.2.0 çekirdeği, Olaf Kirch tarafından geliştirilen ve HJ Lu, G. Allan Morris ve Trond Myklebust tarafından geliştirilen deneysel bir çekirdek tabanlı NFS sunucusunu destekler. Çekirdek tabanlı NFS desteği, sunucu performansında önemli bir artış sağlar.

NFS sunucusu çekirdeğe taşındıktan sonra performansı artırmak için kimsenin tekrar çıkarması için herhangi bir sebep göremediğini düşünüyorum.

Starnamer haklı (beta test uzmanlarından biriydim).

Çekirdeğe koymak, kötü niyetli performansı (özellikle PCNFS istemcileri için) iyileştirme girişimi idi ve bir kez bu sorun çözüldüğünde, kimse tekrar çok baktı.

Çekirdekte NFS'de bulunma konusunda birtakım eksiklikler var, bunların çoğu, aynı dosya sistemine dokunan başka hiçbir şeyle hoş karşılamıyor (ciddi derecede kötü yolsuzluk riskleri var) ama o zaman (1993-4) bunun bir sorun olacağının farkında değilsin.

Biz daha genç ve daha aptaldık, vb.