导读 去年 3 月，专有文件系统供应商 Paragon Software 发布了一系列关于三星衍生的 exFAT 实现进入 Linux 内核的反开源 FUD 流。几

去年 3 月，专有文件系统供应商 Paragon Software 发布了一系列关于三星衍生的 exFAT 实现进入 Linux 内核的反开源 FUD 流。几个月后，Paragon 似乎已经看到了它的方式的错误，并开始 了将自己的 Microsoft NTFS(所有 Windows 机器的默认文件系统)的实现也纳入内核的艰巨过程。

尽管 Paragon 显然仍在努力使其流程和实践与开源友好的流程和实践保持一致，但 Linux 内核BDFL Linus Torvalds 似乎对这个过程产生了个人兴趣。经过 Paragon 近一年的努力，Torvalds 继续温和地推动它和持怀疑态度的 Linux 开发人员，以保持项目向前发展。

为什么是百丽宫?

对于那些熟悉 Linux 日常使用的人来说，Paragon 版本的 NTFS 的效用可能不是很明显。Linux 内核已经有一个 NTFS 实现，而且大多数发行版都非常容易安装和使用另一个基于 FUSE 的实现 (ntfs-3g)。

然而，两种现有的实现方式都存在问题。NTFS 的内核实现非常陈旧，维护不善，只能以只读方式使用。因此，大多数真正需要在 Linux 上挂载 NTFS 文件系统的人都使用 ntfs-3g 驱动程序。

Ntfs-3g 的状态相当不错——它比内核中的 ntfs 实现要新得多，而且正如 Linux 文件系统大师 Ted Ts'o指出的那样，它实际上比 Paragon 自己的 ntfs3 通过了更多的自动化文件系统测试。

不幸的是，由于在用户空间而不是在内核中运行，ntfs-3g 的性能非常糟糕。在 Ts'o 的测试中，Paragon 的 ntfs3 在 8,106 秒内完成了自动化测试——但基于 FUSE 的 ntfs-3g 需要惊人的 34,783 秒。

撇开错误和性能不谈，持续维护是 Paragon ntfs3 使其进入内核的一个关键方面。Torvalds 认为“Paragon 应该只是为 [ntfs3] 提出一个拉取请求”——但他在注意到代码应该从当前维护者那里获得 OK 并且 Paragon 本身应该维护代码之后这样做了。(Paragon 开发人员 Konstantin Komarov 很快回复说，一旦接受，公司打算继续维护代码。)

为什么不是帕拉贡?

尽管 Torvalds 本人似乎对让 Paragon 的 ntfs3 驱动程序主线持积极态度，其他一些用户和开发人员也是如此，但仍然有些人担心 Paragon 及其工作流程是否正确集成到内核开发社区并达到该社区的标准。

Ted Ts'o — Linux ext3/ext4 文件系统的核心维护者，以及用于管理它们的 e2fsprogs 用户空间实用程序 — 似乎是最关键的。除了他在 Paragon 的代码中发现的失败自动化测试数量略高之外，他还指出了其他问题，例如 如果 ntfs3 压力过大，则会出现整个系统死锁。(这也是我们多年来从购买 Paragon ntfs3 的人那里听到的一个问题。)

Ts'o 还提出了关于维护和沟通的问题，他说：“如果 Paragon Software 的*某人*回应 Darrick [Wong] 和我对他们的质量保证的询问，和/或做出他们至少会这样做的承诺，我会感觉更好*尝试*解决使用 fstests 进行大约 5 分钟的测试时出现的问题。”

另一位开发人员 Darrick Wong 补充说，他希望确保 Paragon 投入维护向前推进，这样 ntfs3 就不会“成为像 [当前内核中的 ntfs] 那样破旧的 Linux 文件系统驱动程序之一”。

前进的道路

尽管 Ts'o 和 Wong 持怀疑态度，但我们普遍预计最终会包含 Paragon 的 ntfs3。到目前为止，该公司已经工作了一年，将其代码从被扔到墙上的27,000 行代码 转换为 Linux-ready 补丁集——尽管主要开发人员 Komarov 可能并不总是像 Ts'o 和 Wong 喜欢的那样迅速或彻底地回复，他确实会继续回应。

就他自己而言，Torvalds 似乎决心在内核中找到一种高性能、现代、可维护的替代品，以替代古老(2001 年时代)且很少使用的 ntfs 实现。只要 Paragon 仍然愿意继续玩，它似乎最终会到达那里——甚至可能赶上 5.15 内核。