我将以 Linux NTFS 驱动程序为例。
Linux 内核 NTFS 驱动程序在内核中的写入支持非常有限，5 年后仍被认为是实验性的。
同一开发团队创建了 ntfsmount 用户空间驱动程序，该驱动程序具有几乎完美的写入支持。
同样，由不同团队编写的 NTFS-3G 项目也有几乎完美的写入支持。
为什么内核驱动器花了这么长时间？开发难度更大吗？
说已经存在一个像样的用户空间应用程序并不是内核驱动程序不强制的原因。
注意：不要将此迁移到 superuser.com。从编程的角度来看，我想要一个编程重的答案，而不是实际使用的答案。如果这个问题不适合 SO，请告诉我为什么这样我可以编辑它。
我不知道 NTFS linux 驱动程序开发的内幕，但我可以想象一些事情会使用户空间开发比内核空间更快：
重要的是要注意，特别是在 Linux 中，实验性也可能意味着“有人在这里倾倒的代码，当时看起来可以接受，但可能没有得到积极维护”。
我非常喜欢将文件系统保存在用户空间中，但我也应该表明我是一个微内核的狂热爱好者。我发现将文件系统保留在用户空间中是实用且可取的，原因如下：
用户空间文件系统更容易维护
花点时间看一下ext3cow 文件系统，这是一个 PHD 项目，它在很短的时间内获得了相当大的关注。它的作者毕业了，然后开始了职业生涯，几乎没有时间研究文件系统。由于它是树外的，Linux 在版本之间不断变化的内部结构要求任何想要在现代内核上使用它的人都拥有很多人都不具备的深入知识。
如果它使用 FUSE API，它会更容易维护，并且将 ext3 转换为写入文件系统的副本的实际工作将获得更多曝光。这也与积累霉菌的内核代码有关，因为没有人足够勇敢（或足够无聊）去触摸它。
用户空间文件系统更容易调试
在用户空间中，您拥有非常棒的工具，例如 Valgrind（以及它的朋友，例如 massif），它们是非常宝贵且易于使用的工具。与内核调试相关的学习曲线对于许多人来说通常太长而无法直接进入并编写代码。请注意，我正在明确区分 FUSE 和微内核架构，如本答案中所述。一些基于微内核的系统非常难以调试，主要是由于正在运行的服务（vfs、块设备、文件系统、ipc）之间的通信竞争。在这两种情况下，代码更容易调试，因为它在内核之外，只要它在内核之外不会引入奇怪的复杂性。
无论如何，我将在printk()任何一天将 GDB 和 Valgrind 放在嘈杂的调试中，或者尝试从 Linux 中存在的相当神秘的内核调试钩子中弄清楚。我还将享受使用我选择的任何调试（甚至垃圾收集）malloc()实现的能力。我选择的 C 库也是如此，前提是它可以与 FUSE 一起使用。我没有拒绝 Linux 的内核库，但我喜欢我的物质享受。
用户空间文件系统更易于使用
对于弱势用户来说，能够挂载和维护他们想要使用的任何文件系统是一个很大的好处，但这实际上是最终的结果。如果您的文件系统在内核之外，它可以独立于内核进行升级，这意味着用户可以根据您的发布周期进行升级。可以想象，在 Linux 升级到下一个候选版本所需的时间内，您可以实现 6 个里程碑版本。这也允许发行版和 OEM 供应商将您的 FS 放到野外，它可以比它是内核模块更快地获得所需的测试。
Norman Ramsey已经描述了与文件系统相关的可靠性因素，即微内核架构中的服务。但是，可靠性意味着不需要倾向于隐藏（或推迟）错误和其他问题的轮回服务。我确实同意这样的观点，即如果失败的根挂载不会引发内核中止，这很好，但是这对于启用 FUSE 的单片内核也是可能的。
总而言之，编写文件系统已经够难了，无需处理在内核空间中运行的问题。我更愿意使用 FUSE API，或者研究基于微内核的操作系统中的 IPC / VFS 服务实现，而不是将其编写为内核模块。
内核代码必须满足比用户模式代码更高的安全性和安全性（即无错误）标准。
在用户空间中，您可以使用更多好东西，因此开发软件更容易。如果文件系统位于用户空间，文件系统中的故障就更难导致整个内核崩溃。
这一原则在像Mach和 Windows NT这样的项目中被发挥到了极致，在这些项目中，系统是用微内核设计的，并且尽可能多的服务放在用户空间中。