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.

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!

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 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.