Почему в ядре реализован сервер Linux NFS, а не пользовательское пространство?

Мне просто интересно, почему в ядре реализован сервер Linux NFS, а не пользовательское приложение?

Я знаю, что демон NFS в пользовательском пространстве существует, но это не стандартный метод предоставления служб сервера NFS.

Я бы подумал, что запуск NFS-сервера в качестве приложения пользовательского пространства будет предпочтительным подходом, поскольку он может обеспечить дополнительную безопасность, если демон запускается в пользовательском пространстве вместо ядра. Это также соответствовало бы общепринятому принципу Linux: делать что-то одно и делать это хорошо (и что демоны не должны работать для ядра).
Фактически, единственное преимущество, которое я могу себе представить в работе ядра, - это повышение производительности от переключения контекста (и это спорная причина).

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

unfs3насколько я знаю, мертв; Ganesha - самый активный проект NFS-сервера для пользователей на данный момент, хотя он еще не полностью разработан.

Хотя Samba обслуживает разные протоколы, это пример успешного файлового сервера, который работает в пространстве пользователя.

Я не видел недавнего сравнения производительности.

Некоторые другие вопросы:

• Обычные приложения ищут файлы по пути, но nfsdдолжны иметь возможность искать их по дескриптору файла. Это сложно и требует поддержки со стороны файловой системы (и не все файловые системы могут ее поддерживать). В прошлом это было невозможно сделать из пользовательского пространства, но более свежие ядра добавили name_to_handle_at(2)и open_by_handle_at(2)системные вызовы.
• Кажется, я вспоминаю о блокировке вызовов блокировки файлов; Я не уверен, как серверы пространства пользователя обрабатывают их в эти дни. (Вы связываете серверный поток, ожидающий блокировки, или вы опрашиваете?)
• Более новая семантика файловой системы (изменение атрибутов, делегирование, блокировка общего доступа) может быть легче реализована в ядре вначале (теоретически - в большинстве случаев это еще не было)
• Вам не нужно проверять разрешения, квоты и т. Д. Вручную - вместо этого вы хотите изменить свой uid и полагаться на общий код vfs ядра, чтобы сделать это. А в Linux есть системный вызов ( setfsuid(2)), который должен это делать. По причинам, которые я забыл, я думаю, что это оказалось более сложным для использования на серверах, чем должно быть.

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

Короткая версия: хороший вопрос!

Олаф Кирх первоначально разработал версию NFS-сервера для пользовательского пространства и ядра. В своей книге 2000 года «Сетевое администрирование Linux» он говорит:

Ядро 2.2.0 поддерживает экспериментальный NFS-сервер на базе ядра, разработанный Олафом Кирхом и разработанный Х.Дж. Лу, Дж. Алланом Моррисом и Трондом Миклебустом. Поддержка NFS на основе ядра обеспечивает значительное повышение производительности сервера.

Я думаю, что после того, как NFS-сервер был добавлен в ядро ​​для повышения производительности, никто не видел причин снова его использовать.

Starnamer правильно (я был одним из бета-тестеров).

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

Имеется ряд недостатков, связанных с наличием NFS в ядре, не в последнюю очередь из-за того, что он плохо работает с чем-либо, касающимся той же файловой системы (существуют серьезные неприятные риски повреждения), но тогда (1993-4) мы не делали этого. не понимаю, что это окажется проблемой.

Мы были моложе и глупее и т. Д.