Dlaczego serwer Linux NFS jest implementowany w jądrze w przeciwieństwie do przestrzeni użytkownika?

Zastanawiałem się tylko, dlaczego serwer Linux NFS jest zaimplementowany w jądrze, a nie aplikacja w przestrzeni użytkownika?

Wiem, że istnieje demon NFS w przestrzeni użytkownika , ale nie jest to standardowa metoda świadczenia usług serwera NFS.

Wydaje mi się, że preferowanym podejściem byłoby uruchomienie serwera NFS jako aplikacji w przestrzeni użytkownika, ponieważ może on zapewnić dodatkowe bezpieczeństwo dzięki uruchamianiu demona w przestrzeni użytkownika zamiast w jądrze. Pasowałoby to również do wspólnej zasady Linuksa polegającej na robieniu jednej rzeczy i robieniu tego dobrze (i że demony nie powinny być zadaniem dla jądra).
W rzeczywistości jedyną korzyścią, jaką mogę myśleć o uruchomieniu w jądrze, byłoby zwiększenie wydajności z przełączania kontekstu (i jest to dyskusyjny powód).

Czy jest więc jakiś udokumentowany powód, dla którego jest wdrażany w taki sposób? Próbowałem googlować po okolicy, ale nic nie znalazłem.

Wydaje się, że jest wiele zamieszania, proszę zauważyć, że nie pytam o montowanie systemów plików, pytam o udostępnienie po stronie serwera sieciowego systemu plików . Istnieje bardzo wyraźna różnica. Lokalne podłączenie systemu plików wymaga obsługi systemu plików w jądrze, pod warunkiem, że tak nie jest (np. Samba lub unfs3).

linux kernel nfs

— Patrick
źródło

NFS to system plików. Sterowniki systemu plików przestrzeni użytkownika muszą korzystać z bezpiecznika FUSE, który zazwyczaj jest słaby pod względem wydajności.

— jordanm,

@jordanm nie, nie robią tego. W rzeczywistości nie można uruchamiać sieciowych systemów plików (NFS, CIFS / samba, coda itp.) Przez FUSE. FUSE służy do montowania systemów plików na komputerze lokalnym, a nie ich obsługi.

— Patrick,

masz rację, moje oświadczenie dotyczyłoby tylko klienta.

— jordanm,

@jordanm nawet niestety. Możesz montować systemy plików bez BEZPIECZNIKA. FUSE i tak jest stosunkowo nową technologią, po stronie klienta sieciowych systemów plików istniało na długo przed tym, zanim FUSE :-). FUSE po prostu zapewnia obsługę systemów plików, które nie są dostarczane przez jądro (nie próbuje być złośliwy, tylko chce wyjaśnić nieporozumienia :-P)

— Patrick

@StarNamer nadal mówisz o kliencie. Mówię o serwerze. Możesz uruchomić unfs3(który jest serwerem NFS) bez wsparcia dla jądra.

— Patrick,

Odpowiedzi:

unfs3jest martwy, o ile wiem; Ganesha jest obecnie najbardziej aktywnym projektem serwera NFS w przestrzeni użytkownika, choć nie jest on w pełni dojrzały.

Chociaż obsługuje różne protokoły, Samba jest przykładem udanego serwera plików, który działa w przestrzeni użytkownika.

Nie widziałem ostatniego porównania wydajności.

Niektóre inne problemy:

Zwykłe aplikacje wyszukują pliki według nazwy ścieżki, ale nfsdmuszą mieć możliwość wyszukiwania ich za pomocą uchwytu pliku. Jest to trudne i wymaga wsparcia z systemu plików (i nie wszystkie systemy plików mogą to obsługiwać). W przeszłości nie było to możliwe z przestrzeni użytkownika, ale dodano nowsze jądra name_to_handle_at(2)i open_by_handle_at(2)wywołania systemowe.
Wydaje mi się, że pamiętam, że blokowanie wywołań blokowania plików jest problemem; Nie jestem pewien, jak serwery przestrzeni użytkownika radzą sobie z nimi w dzisiejszych czasach. (Czy wiążesz wątek serwera oczekujący na zamek, czy sondujesz?)
Nowszą semantykę systemu plików (zmiana atrybutów, delegacje, blokady udostępniania) można najpierw łatwiej zaimplementować w jądrze (teoretycznie - w większości jeszcze nie były).
Nie chcesz ręcznie sprawdzać uprawnień, limitów itp. - zamiast tego chcesz zmienić swój identyfikator użytkownika i polegać na wspólnym kodzie vfs jądra, aby to zrobić. A Linux ma wywołanie systemowe ( setfsuid(2)), które powinno to zrobić. Z powodów, o których zapominam, myślę, że korzystanie z serwerów okazało się bardziej skomplikowane niż powinno.

Zasadniczo mocnymi stronami serwera jądra są ściślejsza integracja z vfs i eksportowanym systemem plików. Możemy to nadrobić, udostępniając więcej interfejsów jądra (takich jak wywołania systemowe uchwytów plików), ale to nie jest łatwe. Z drugiej strony niektóre systemy plików, które ludzie chcą obecnie wyeksportować (jak gluster), tak naprawdę żyją głównie w przestrzeni użytkownika. Można je wyeksportować przez jądro nfsd za pomocą FUSE - ale znowu rozszerzenia do interfejsów FUSE mogą być wymagane w przypadku nowszych funkcji i mogą wystąpić problemy z wydajnością.

Krótka wersja: dobre pytanie!

— J. Bruce Fields
źródło

Czytelnicy powinni zauważyć, że Bruce jest (a? The?) Opiekunem linuksowego serwera NFS, więc prawdopodobnie wie, o czym mówi. :)

— Dan Pritts,

@derfian FYI - możesz skomentować tutaj, że „ unfs3żyje i przenosi się do Github” ?

— ms-ati

Skomentowałem powyższe, ponieważ @derfian lub użytkownik StackOverflow ( unix.stackexchange.com/users/23034/derfian ), jest opiekunem unfs3, a ostatnio ogłosił, że nie jest martwy, na przykład w tym komentarzu Github

— ms-ati

Odpowiedź napisana przez opiekuna NFS jest dość niejasna.

— Torsten Bronger

Olaf Kirch pierwotnie opracował wersję serwera NFS opartą na przestrzeni użytkownika i jądrze. W swojej książce z 2000 roku „Linux Network Administration” mówi:

Jądro 2.2.0 obsługuje eksperymentalny serwer NFS oparty na jądrze, opracowany przez Olafa Kircha i rozwinięty przez HJ Lu, G. Allana Morrisa i Tronda Myklebusta. Obsługa NFS oparta na jądrze zapewnia znaczny wzrost wydajności serwera.

Myślę, że kiedy serwer NFS został przeniesiony do jądra w celu poprawy wydajności, nikt nie widział powodu, aby go ponownie usunąć.

— StarNamer
źródło

Starnamer ma rację (byłem jednym z beta testerów).

Umieszczenie go w jądrze było próbą poprawienia beznadziejnej wydajności (głównie dla klientów PCNFS), a gdy problem został rozwiązany, nikt więcej na niego nie patrzył.

Istnieje wiele braków w posiadaniu NFS w jądrze, między innymi dlatego, że nie działa on dobrze z niczym innym dotykającym tego samego systemu plików (istnieje poważne paskudne ryzyko uszkodzenia), ale wtedy (1993-4) nie nie zdaję sobie sprawy, że okaże się to problemem.

Byliśmy młodsi i bardziej głupi itp. Itd.

— stoatwblr
źródło