我的 NTFS 驱动器上的游戏遇到一些性能问题。我在 Linux 和 Windows 之间共享一个 Steam 库，该库驻留在 PCIe4 NVME、NTFS 格式上。与从我的 ext4（也在 pcie4 NVME 上运行）相比，运行例如 Baldur's Gate 3 的加载速度非常慢。差异是惊人的，15 秒 vs 60 秒。然而，这两个驱动器在读取规格方面相似。加载时 ntfs-3g 驱动程序还会导致 CPU 峰值。
我尝试了几乎所有的方法来提高性能，比如 noatime、big_writes 之类的，但没有任何效果。直到我尝试了lowntfs-3g。我尝试将其作为最后的手段，并且成功了。速度非常快，和 ext4 一样快！
那么，我错过了什么？有什么缺点？我未能在互联网或手册页上找到任何相关信息。
我使用的是 Ubuntu 22.04 (KDE Neon 5.27) 和 Xanmod 内核 6.4.10。
答案1
是的，这是一件令人惊讶的没有记录的事情。
所以，诚实的答案是：ntfs-3g和lowntfs-3g是两个不同的 NTFS 驱动程序。他们确实共享一些代码，但实际上在关键功能中并没有那么多，例如fuse_ntfs_read：NTFS-3G版本,lowntfs-3g版本。
顾名思义，lowntfs-3g 使用较低级别的 FUSE API，而且看起来速度更快。我不能说这是因为低级 FUSE API 更快，还是因为代码似乎更新了几年，他们只是从第一次修订中学习。
man 8 ntfs-3g告诉我们只有 lowntfs-3g 可以忽略大小写并将所有文件名小写，而只有 ntfs-3g 可以处理替代数据流（如果您没有听说过这些，请原谅！）。
因此，本质上，同一个软件包，NTFS 驱动程序的两种不同实现。开发人员没有明确建议使用其中之一。
我想 ntfs-3g 更有可能经过彻底的测试，因为这是每个人和他们的祖母默认的设置 - 正如我所做的那样，你也所做的那样。错误应该会更早被发现。
我有点惊讶 ext4 只比 ntfs-3g 快四倍！顺便说一句，这对于 FUSE 驱动器来说是一项巨大的成就；通常，对文件的任何访问（例如在 ext4 上）只需要程序进行系统调用，这会保存处理器状态（描述正在执行的程序中的点以及 CPU 中的所有相关寄存器）和调度状态，以及在内核中获取数据的动作；一旦内核完成获取程序所需的数据，程序的执行就可以继续，因此保存执行内核代码时的进程状态，以及执行程序代码时的处理器状态被恢复，CPU 跳回到程序执行系统调用时停止的位置。 （细节当然比较复杂，但这就是基本思想。）
在 FUSE（USERland 中的文件系统）中，您的程序执行系统调用（保存程序状态，恢复内核状态），内核确定您询问的文件位于 FUSE 文件系统上，找出哪个文件，然后调用该文件系统的函数用户态驱动程序（保存内核状态，恢复 FUSE 程序状态），该文件系统驱动程序确定需要从底层块设备读取什么内容，并执行系统调用来执行该读取（保存 FUSE 状态，恢复内核状态），内核读取，返回数据（保存内核状态，恢复FUSE程序状态），然后FUSE驱动程序根据请求组装数据，并将其返回给内核（保存FUSE程序状态，恢复内核状态），然后内核可以将请求的数据（如果完整！）交给程序（保存内核状态，恢复程序状态）。
因此，FUSE 实际上是一场上下文切换的邪恶盛宴（至少 6 次而不是 2 次），其中大量 CPU 缓存可能会受到冲击。这对性能来说确实很糟糕（单个读取请求越小，效果就越差！）。这就是为什么我对 ntfs-3g 的性能感到非常惊讶，并且惊讶根据您报告的低ntfs-3g性能！