![在同一个池上运行两次 zfs trim 仍然需要很长时间](https://linux22.com/image/771620/%E5%9C%A8%E5%90%8C%E4%B8%80%E4%B8%AA%E6%B1%A0%E4%B8%8A%E8%BF%90%E8%A1%8C%E4%B8%A4%E6%AC%A1%20zfs%20trim%20%E4%BB%8D%E7%84%B6%E9%9C%80%E8%A6%81%E5%BE%88%E9%95%BF%E6%97%B6%E9%97%B4.png)
我有一个由两个镜像 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 运行中受益。