为什么当我将 XFS 文件系统放在上面时，我的 SSD 读取延迟基准会明显变差？

Question

我正在对基于SuperMicro E300-8D的小型服务器盒进行基准测试。我已经安装了带有最新更新的最新 CentOS 7.5、64GB DDR4-2100 RAM 和三星 970 EVO 1TB NVMe SSD。操作系统安装在 USB 记忆棒上的内部 USB 端口中，因此除了在我的基准测试期间，SSD 完全没有使用。

受ScyllaDB使用的基准测试方法的启发，我的测试目标是找到此 SSD 的最佳并发级别。为此，我使用了diskplorer，它在内部用于fio探索并发与 IOPS 和延迟之间的关系。它会生成如下所示的方便图表。在所有情况下，我都使用 4K 随机读取工作负载。

问题是我得到的结果毫无意义。这是第一个结果：

生的 /dev/nvme0n1

$ sudo ./diskplorer.py --device=/dev/nvme0n1 --filesize=256G 

这是太棒了！三星自己的规格表声称读取 IOPS 为 500K，20 次并发读取时，我得到了近 600K。右边的轴是以纳秒为单位的读取延迟，红线是平均延迟，误差线是 5% 和 95% 的延迟。所以看起来这个 SSD 的理想并发级别是大约 20 次并发读取，产生极好的延迟 < 100us。

那只是原始SSD。我会将 XFS 放在上面，它针对异步 I/O 进行了优化，而且我确信它不会增加任何显着的开销......

使用新的 XFS 文件系统 /dev/nvme0n1

$ sudo mkfs.xfs /dev/nvme0n1
$ sudo mount /dev/nvme0n1 /mnt
$ sudo ./diskplorer.py --mountpoint=/mnt --filesize=256G 

什么！？这是可怕的！XFS 似乎引入了一些荒谬的延迟并显着降低了 IOPS。可能有什么问题？

以防万一，重新启动系统以清除缓存，而不是缓存应该是全新文件系统的一个因素：

/dev/nvme0n1重启后XFS 开启

$ sudo shutdown -r now
(reboot happens)
$ sudo mount /dev/nvme0n1 /mnt
$ sudo ./diskplorer.py --mountpoint=/mnt --filesize=256G 

没变。它与缓存无关。

此时 上有一个有效的 XFS 文件系统/dev/nvme0n1，并且它被挂载到/mnt. 我将重复我首先在未挂载的原始块设备上进行的测试，同时保留 XFS 文件系统的内容。

再次生/dev/nvme0n1

$ sudo umount /mnt
$ sudo ./diskplorer.py --device=/dev/nvme0n1 --filesize=256G 

哦不，XFS 毁了我的 SSD 性能！ /sarcasm

显然，XFS 并不是恶魔般地破坏了我的 SSD 性能，或者 XFS 不适合这种工作负载。但它可能是什么？即使卸载磁盘以便不涉及 XFS，性能似乎也大大降低了？

凭直觉，我尝试DISCARD了 SSD 的全部内容，这应该将磁盘内单元的分配重置为其原始状态......

生/dev/nvme0n1后blkdiscard

$ sudo blkdiscard /dev/nvme0n1
$ sudo ./diskplorer.py --device=/dev/nvme0n1 --filesize=256G

奇迹般地，我的SSD的性能恢复了。全世界都疯了吗？

根据@shodanshok 的建议，如果我dd在通过执行“修复”SSD 后对 SSD 执行 ablkdiscard怎么办？

生/dev/nvme0n1后，blkdiscard再与归零dd

$ sudo blkdiscard /dev/nvme0n1
$ sudo dd if=/dev/zero of=/dev/nvme0n1 bs=1M status=progress oflag=direct
$ sudo ./diskplorer.py --device=/dev/nvme0n1 --filesize=256G 

这是一个有趣的结果，并证实了我的信念，即 XFS 不应归咎于此。仅仅通过用零填充 SSD，读取延迟和吞吐量都显着恶化。所以一定是 SSD 本身对未分配的扇区有一些优化的读取路径。

假设

显然 XFS 并没有杀死我的 SSD，如果是，blkdiscard也不会神奇地恢复它。我再次强调，这些基准测试都是读取基准测试，因此写入日志、写入放大、磨损均衡等问题不适用。

我的理论是，这个 SSD 和通常的 SSD 在读取路径上有一个优化，它检测对磁盘未分配区域的读取，并执行高度优化的代码路径，通过 PCIe 总线将所有零发送回。

我的问题是，有谁知道这是否正确？如果是这样，没有文件系统的新 SSD 的基准测试通常是否值得怀疑，并且这是否在任何地方都有记录？如果这不正确，有没有人对这些奇怪的结果有任何其他解释？

Answer 1

大多数现代 SSD 使用基于页面的映射表。起初（或在完成 TRIM/UNMAP 之后）映射表是空的——即任何 LBA 都返回 0，即使底层闪存页面/块没有被完全擦除，因此其实际值与普通 0 不同。

这意味着，在完成之后blkdiscard，您不是从闪存芯片本身读取；相反，控制器会立即将 0 返回给您的所有读取。这很容易解释你的发现。

一些更古老的 SSD 使用不同的、效率较低但更简单的方法，这些方法总是从 NAND 芯片本身读取。在这样的驱动器上，修剪的页面/块的值有时是不确定的，因为控制器不是简单地将它们标记为“空”，而是每次都从 NAND 读取。

是的，SSD是比“普通”HDD 更复杂的野兽：毕竟，它们基本上是小型、自动包含、精简配置的 RAID 卷，具有自己的文件系统/卷管理，称为FTL（闪存转换层）。