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

33

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

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

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

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


Кажется, здесь много путаницы, обратите внимание, я не спрашиваю о монтировании файловых систем, я спрашиваю о предоставлении серверной части сетевой файловой системы . Существует очень четкая разница. Для монтирования файловой системы локально требуется поддержка файловой системы в ядре, если этого не происходит (например, samba или unfs3).

Патрик
источник
NFS - это файловая система. Драйверы файловой системы в пользовательском пространстве должны использовать FUSE, что, как правило, приводит к снижению производительности.
Иордания
@ Джорданм нет, нет. Фактически вы не можете запускать сетевые файловые системы (NFS, CIFS / samba, coda и т. Д.) Через FUSE. FUSE предназначен для монтирования файловых систем на локальном компьютере, а не для их обслуживания.
Патрик
Вы правы, мое заявление будет относиться только к клиенту.
Иордания
@jordanm даже не это, к сожалению. Вы можете монтировать файловые системы без FUSE. В любом случае, FUSE является относительно новой технологией, клиентская сторона сетевых файловых систем существовала задолго до того, как это сделал FUSE :-). FUSE просто предоставляет способ поддержки файловых систем, не предоставляемых ядром (не пытаясь быть злым, просто надеясь прояснить неправильные представления :-P)
Патрик
2
@StarNamer вы все еще говорите о клиенте. Я говорю о сервере. Вы можете запустить unfs3(это сервер NFS) без какой-либо поддержки ядра.
Патрик

Ответы:

25

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, а также могут возникнуть проблемы с производительностью.

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

Дж. Брюс Филдс
источник
2
Читатели должны заметить, что Брюс (a? The?) Сопровождает NFS-сервер linux, так что, вероятно, он знает, о чем говорит. :)
Дэн Притц
@derfian FYI - вы можете прокомментировать здесь, что « unfs3жив и движется в Github» ?
MS-ATI
Я прокомментировал вышеизложенное, потому что @derfian, или пользователь StackOverflow ( unix.stackexchange.com/users/23034/derfian ), является разработчиком unfs3 и недавно объявил, что он не умер, например, в этом комментарии Github
ms-ati,
Для написанного сопровождающим NFS этот ответ довольно расплывчатый.
Торстен Бронджер
18

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

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

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

StarNamer
источник
8

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

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

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

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

stoatwblr
источник