为什么在内核中而不是用户空间中实现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接口，并且可能存在性能问题。

简短版：好问题！

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

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

我认为，一旦将NFS服务器移入内核以提高性能，没有人会发现有任何理由再次将其淘汰。

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

将其放到内核中是一种尝试提高超乎寻常的性能（主要是针对PCNFS客户端）的尝试，而一旦解决了该问题，就没有人再次关注它。

在内核中拥有NFS有很多缺陷，其中最重要的是它不能很好地与触摸同一文件系统的其他任何东西配合使用（存在严重的腐败风险），但那时（1993-4）我们没有没有意识到这将成为一个问题。

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