我想测量我的 SSD 读/写性能，并找到了一些使用 dd 和 gnome-disks 的建议。 （根据我的理解，hdpart 不相关，因为它不使用磁盘本身，而只使用缓存的数据）。
问题是我使用这些工具得到了不同的结果，我希望了解为什么会发生这种情况。
rootfs 从本地内部 eMMC 挂载，SSD 具有挂载的 ext4 文件系统。
谢谢
答案1
长话短说
两者都是不当测试存储性能的方法。两者都没有说明你的系统存储性能，而 dd 几乎没有说明你的 SSD 性能（但是，我更喜欢 gnome 的基准测试而不是 dd，这是衡量存储的完全错误的方法）。
使用fio，它被广泛认为是测试存储性能的正确方法。
解释
存储子系统有大量不同的优化选项等等。
dsync选择使用同步输入/输出，这意味着它就像一个循环：发送请求，等待（轮询）直到完成，发送下一个请求等等。这会比较慢，因为在适当的异步场景中，您会在旧请求仍在运行时对下一个请求进行排队，从而将浪费的 CPU 周期投入使用。此外，它不允许您充分利用现代 SSD 提供的并行性。
此外，吞吐量并不是存储的唯一指标，当然也不是最重要的指标。顺便说一句，它仅对备份和文件服务很重要。经常潜伏是最受关注的，并且提到的并行性是值得赞赏的。例如，存储延迟定义了 OLTP 数据库的性能（遵循 ACID 原则）。
此外，延迟和并行性共同定义了“每秒 I/O 操作数”指标，该指标通常用于比较存储，但该指标也很模糊，因为很难预测将执行哪些操作，而 IOPS 取决于此。
无论如何，这些都是 SSD 真正优于基于 Rust 的旋转解决方案的指标。您可以用 100 个 HDD 构建一个 RAID 阵列，该阵列将具有 10GiB/s 吞吐量和 100 路并行性，但仍然显示普通 HDD 的延迟，从这个角度来看，在某些数据库负载下，它的性能将低于 600 MiB/s SSD。
你们的两个工具都没有提到任何关于并行性的内容，只有 gnome 的工具提到了延迟（他们称之为“访问时间”）。
fio另一方面，显示每个请求的延迟分布（本质上它是一个直方图，在 0.1 毫秒内处理了多少个请求，有多少个请求在 0.1 到 0.2 之间等等），因此您可以构建应用程序的真实期望将在该存储上执行部署。它允许您探索并行性。它甚至有一种模式可以找到队列和并行参数来保证一些设定的目标延迟，当您需要回答“我的服务器将维持多少用户/并发请求而不会减慢”之类的问题时，这非常有用。