我正在根据以下标准对一个小型服务器盒进行基准测试SuperMicro E300-8D。我安装了最新的 CentOS 7.5 和最新更新、64GB DDR4-2100 RAM 和三星 970 EVO 1TB NVMe SSD。操作系统安装在内部 USB 端口的 USB 记忆棒上，因此除了基准测试期间外，SSD 完全未使用。
我的测试目标是找到此 SSD 的最佳并发级别，灵感来自ScyllaDB.为此，我使用磁盘探查器它内部用于fio探索并发性与 IOPS 和延迟之间的关系。它生成了如下图所示的便捷图表。在所有情况下，我都使用 4K 随机读取工作负载。
问题是我得到的结果毫无意义。这是第一个结果：
生的/dev/nvme0n1
$ sudo ./diskplorer.py --device=/dev/nvme0n1 --filesize=256G
这太棒了！三星自己的规格表声称读取 IOPS 为 500K，而通过 20 次并发读取，我几乎获得了 600K。右侧的轴是纳秒内的读取延迟，红线是平均延迟，误差线是 5% 和 95% 的延迟。因此，看起来这款 SSD 的理想并发级别约为 20 次并发读取，从而产生小于 100 微秒的惊人延迟。
那只是原始的 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 之后再对其进行 “修复”，会怎么样blkdiscard？
原始/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 的基准测试是否普遍值得怀疑，这有记录吗？如果这不正确，有人对这些奇怪的结果有其他解释吗？
答案1
大多数现代 SSD 使用基于页面的映射表。最初（或完成 TRIM/UNMAP 之后）映射表为空 - 即任何 LBA 都返回 0，即使底层闪存页面/块没有完全消除所以它的实际值与普通的 0 不同。
这意味着，在完成之后blkdiscard，你不是控制器不会自己读取闪存芯片；相反，控制器会立即向所有读取返回 0。这很容易解释您的发现。
一些更古老的 SSD 使用不同的、效率更低但更简单的方法，它们总是从 NAND 芯片本身读取数据。在这样的驱动器上，修剪页面/块的值有时是不确定的，因为控制器不是简单地将它们标记为“空”，而是每次都从 NAND 读取数据。
是的，SSD是比“普通”硬盘更复杂的是：毕竟，它们基本上是小型、自动包含、精简配置的 RAID 卷，具有自己的文件系统/卷管理，称为FTL（闪存转换层）。
答案2
只是为了增强@shodanshok 的正确答案：
没有文件系统的新 SSD 的基准测试是否普遍值得怀疑，是否有任何记录？
是的，未经“预处理”的 SSD 基准测试（以及仅使用零数据的基准测试和...）通常值得怀疑。这在几个地方有记录：
- https://www.seagate.com/gb/en/tech-insights/lies-damn-lies-and-ssd-benchmark-master-ti/警告“在进行测量之前，必须对 SSD 进行充分且适当的预处理”
- https://www.snia.org/sites/default/files/technical_work/PTS/SSS_PTS_2.0.1.pdf有一套详尽的 SSD 基准测试指南
- http://codecapsule.com/2014/02/12/coding-for-ssds-part-6-a-summary-what-every-programmer-should-know-about-solid-state-drives/对 SSD 的工作原理有很好的描述。
一般来说，虽然它从未明确提到你需要在进行基准测试之前填充 SSD，因为读取“从未”写入的数据可能会人为地更快，但你可以争辩说它们都假设了预处理。
PS：在 Linux 上，fio当以 root 权限运行时，它知道如何使“常规” I/O 的磁盘缓存无效，并且默认情况下会这样做（https://fio.readthedocs.io/en/latest/fio_man.html#cmdoption-arg-invalidate）。