Чому Linux NFS-сервер реалізований в ядрі на відміну від простору користувачів?

Мені було просто цікаво, чому сервер Linux NFS реалізований у ядрі, на відміну від додатка простору користувачів?

Я знаю, що демон NFS у просторі користувачів існує, але це не стандартний метод надання сервера NFS.

Я думаю, що найкращим підходом буде запуск сервера NFS як програми для користувальницького простору, оскільки він може забезпечити додаткову безпеку, що має демоновий запуск у просторі користувачів замість ядра. Він також підходив би до загального директора Linux, який займався однією справою і робив це добре (і що демони не повинні бути роботою для ядра).
Насправді єдина користь, яку я можу подумати про запуск у ядрі, - це підвищення продуктивності від переключення контексту (і це є дискусійною причиною).

То чи є якась документально підтверджена причина, чому вона реалізується такою, якою вона є? Я спробував гугнути навколо, але нічого не зміг знайти.

unfs3наскільки я знаю, мертвий; Ганеша - це найактивніший проект сервера NFS на даний момент, хоча він не повністю зрілий.

Хоча він обслуговує різні протоколи, Samba є прикладом успішного файлового сервера, який працює в просторі користувачів.

Я не бачив останніх порівнянь ефективності.

Деякі інші проблеми:

• Звичайні програми шукають файли за назвою шляху, але nfsdпотрібно мати можливість їх шукати за допомогою файлових файлів . Це складно і вимагає підтримки файлової системи (і не всі файлові системи можуть її підтримувати). Раніше цього не можна було зробити з простору користувачів, але новіші ядра додали name_to_handle_at(2)і open_by_handle_at(2)системні виклики.
• Здається, я пам'ятаю, що блокування дзвінків із блокуванням файлів є проблемою; Я не впевнений, як сервери простору користувачів обробляють їх сьогодні. (Ви пов’язуєте серверну нитку, яка чекає на замок, або ви опитуєте?)
• Новіша семантика файлової системи (зміни атрибутів, делегування, блокування обміну) може бути запроваджена спочатку в ядрі (теоретично - вони здебільшого ще не були).
• Вам не потрібно вручну перевіряти дозволи, квоти тощо - замість цього ви хочете змінити свій uid і покластися на загальний код vfs ядра для цього. І в Linux є системний виклик ( setfsuid(2)), який повинен це робити. З причин, які я забуваю, я думаю, що це виявилося складніше використовувати на серверах, ніж це повинно бути.

Взагалі сильні сторони сервера ядра - тісніша інтеграція з vfs та експортованою файловою системою. Ми можемо це компенсувати, надаючи більше інтерфейсів ядра (наприклад, системні дзвінки файлових файлів), але це непросто. З іншого боку, деякі файлові системи, які люди хочуть експортувати в наші дні (як-от глюстер), насправді живуть переважно в просторі користувачів. Вони можуть бути експортовані ядром nfsd за допомогою FUSE, але знову-таки розширення на інтерфейси FUSE можуть знадобитися для нових функцій, і можуть виникнути проблеми з продуктивністю.

Коротка версія: гарне запитання!

Олаф Кірх спочатку розробив як користувацький простір, так і версію сервера NFS на основі ядра. У своїй книзі про 2000 рік "Управління мережею Linux" він говорить:

Ядро 2.2.0 підтримує експериментальний сервер NFS на основі ядра, розроблений Олафом Кірхом та далі розроблений HJ Lu, G. Allan Morris та Trond Myklebust. Підтримка NFS на основі ядра забезпечує значне підвищення продуктивності сервера.

Я думаю, що як тільки сервер NFS перемістився в ядро ​​для підвищення продуктивності, ніхто не бачив причин знову його виводити.

Starnamer вірно (я був одним з бета-тестерів).

Поміщення його в ядро ​​було спробою поліпшити бездоганну продуктивність (головним чином для клієнтів PCNFS), і як тільки ця проблема була вирішена, ніхто більше не переглядав її.

Існує низка недоліків із наявністю NFS в ядрі, не менш важливим з яких є те, що воно не грає добре, якщо нічого іншого не торкається тієї самої файлової системи (є серйозні неприємні корупційні ризики), але тоді (1993-4) ми цього не робили Я не розумію, що це виявиться проблемою.

Ми були молодші і дурніші і т. Д. І т.д.