为什么 Linux NFS 服务器在内核中实现而不是在用户空间中实现？

Question

我只是想知道为什么 Linux NFS 服务器是在内核中实现的，而不是用户空间应用程序？

我知道存在用户空间 NFS 守护程序，但这不是提供 NFS 服务器服务的标准方法。

我认为将 NFS 服务器作为用户空间应用程序运行将是首选方法，因为它可以提供额外的安全性，让守护程序在用户空间而不是内核中运行。它也符合做一件事并做好它的常见 Linux 原则（并且守护进程不应该是内核的工作）。
事实上，我能想到的在内核中运行的唯一好处是上下文切换带来的性能提升（这是一个有争议的原因）。

那么是否有任何记录在案的原因，为什么它是这样实施的？我尝试谷歌搜索，但找不到任何东西。

---

似乎有很多混乱，请注意我不是在问挂载文件系统，我问的是提供网络文件系统的服务器端。有一个非常明显的区别。在本地挂载文件系统需要内核支持文件系统，前提是它不支持（例如 samba 或 unfs3）。

Answer 1

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 接口，并且可能存在性能问题。

简短版本：好问题！

Answer 2

Olaf Kirch 最初开发了 NFS 服务器的基于用户空间和内核的版本。在他 2000 年出版的《Linux 网络管理》一书中，他说：

2.2.0 内核支持由 Olaf Kirch 开发并由 HJ Lu、G. Allan Morris 和 Trond Myklebust 进一步开发的实验性基于内核的 NFS 服务器。基于内核的 NFS 支持显着提高了服务器性能。

我认为一旦 NFS 服务器被移入内核以提高性能，就没有人认为有任何理由再次将其移除。

Answer 3

Starnamer 是正确的（我是 Beta 测试者之一）。

把它放在内核中是为了提高糟糕的性能（主要是对 PCNFS 客户端），一旦这个问题得到解决，就没有人再看它了。

在内核中使用 NFS 有许多缺陷，其中最重要的是它不能很好地与其他任何接触相同文件系统的东西一起工作（存在严重令人讨厌的损坏风险）但当时（1993-4）我们没有没有意识到这会成为一个问题。

我们更年轻，更愚蠢，等等。