我有一个由两个镜像 1TB Samsung 870 QVO 驱动器组成的 ZFS 池，我使用它大约一年来将 bhyve 客户机映像存储为 ZVOL。在此期间，我创建/弄乱/销毁了许多 VM 实例；这个池经历了相当多的磁盘活动。
昨晚，在查看其中一台虚拟机的磁盘 I/O 性能时，我意识到我之前从未修剪过这些 SSD。由于不知道会发生什么，我关闭了虚拟机并zfs trim在池上运行。
总体而言，整个操作耗时长达 16 小时（！）。作为参考，以下是gstat -pdo这段时间内发生的事情（典型输出，平均值超过 10 秒）：
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d o/s ms/o %busy Name
11 45 0 0 0.0 27 292 84.9 18 8497 114.3 0 82.9 101.0| ada0
12 37 0 0 0.0 26 283 92.1 11 6547 189.1 0 84.2 100.6| ada1
无论如何，我耐心地让它运行直至完成。
然后，今天早些时候，当所有虚拟机仍处于停止状态时，我决定zfs trim再次运行。我的理由是，由于自上次 TRIM 以来该池上没有重大活动，并且大多数未分配的块据称在第一次运行时已被 SSD 控制器回收，因此这次运行速度会快得多。
好吧，我的直觉错了：这个 TRIM 现在已经运行了大约 5 个小时，根据zpool status -t，它只完成了 30% 多一点。所以显然，我看到的总体运行时间差不多（大约 16 小时）。
这是预期的行为吗？因为如果是的话，那么显然我一定错过了一些有关 TRIM 工作原理的知识。
笔记：
- 我知道 QVO 系列的缺点（4 位 MLC 闪存，众所周知的少量伪 SLC 缓存），所以我一开始并没有期待任何疯狂的性能。
- 也许我的设置有问题（SATA 电缆损坏等），但这仍然不能解释为什么系统似乎没有从同一池上之前的 TRIM 运行中受益。