SMR 叠瓦盘究竟在什么情况下会显著掉速？

（先不要吐槽为啥不上固态之类的……）

想拿到公认是 CMR 而不是 SMR 的 ST2000LM003 （ 2.5 寸 CMR 盘里貌似也只有这个型号是 2TB 了，而且据说很多年前就停产了），为此淘了一块希捷 2T 移动硬盘，感觉像赌石，结果这次赌输了，插到电脑上发现是 ST2000LM007 ，网上搜了一圈基本公认是 SMR ，anandtech 当时还有报道。
据说希捷的 2T 移动硬盘是 2016 年 2 月以前出厂才是 CMR 的 ST2000LM003 ，在此之后就逐渐换成 SMR 的 ST2000LM007 了。

这块 ST2000LM007 在 Crystal Disk Info 里没有显示支持 TRIM 。
出于好奇，楼主用 DiskGenius 选择随机数据进行全盘填充 /清除，总共用了大概 5 个小时，没感觉到速度慢——嗯，应该是因为新盘本来就都是 0 ，还没有条件暴露“脏盘掉速”问题。

但是在此之后，用 HD Tune 跑写入测试（这个测试是强制在没分区的情况下进行的，否则软件拒绝开始），看着写入速度曲线好像并没有什么异常，还是外圈快（ 125MB 左右），越到内圈越慢（最慢也没低于 50MB/s ）。

然后我又整盘分了一个大分区，启用 BitLocker 加密，XTS-AES 128 ，选择只加密可用空间。我觉得 BitLocker 应该可以防止硬盘主控耍压缩之类花招。

先是复制进去了一个 70GB 的大文件，显示速度大概在 100MB/s 以上，没感觉到掉速。

然后我创建了一堆 1GB 的填 0 文件填满分区（最后不足 1GB 也仍然让他填满）——貌似还是没发现有显著的掉速问题，还是最慢也没跌破 50MB/s 。
做成图表，看上去也类似于 HD Tune 跑出来的曲线，只是跑到最后几十 GB 的时候速度会突然变快。用 DiskGenius 定位最后几个文件的数据开始位置 LBA ，好像也并不在靠近外圈的地方，所以不太理解具体原因，也许和 SMR 盘内部的翻译映射有关？

接着我用脚本，让 openssl 先在 ramdisk 里走 aes128cbc 生成 1GB 的伪随机数（每个文件密钥都不一样），再从 ramdisk 复制到这个移动硬盘、覆盖填充上述文件——没跑完我就把它停了，但跑了好一阵子还是没发现显著的掉速问题。

再然后我又用同一份伪随机数据，按文件名反过来的顺序覆盖填充这些 1GB 的文件，结果发现这样跑出来的曲线，左右翻转一下，几乎就是和上述填 0 的实验跑出来的曲线一模一样。

现在我的猜测是，这块（ drive-managed ） SMR 硬盘的主控也许远比我想象的要聪明。
比如……（以下纯脑补）也许写入 1GB 数据的时候，（因为仍然是顺序读写）虽然会覆盖邻近磁轨，但绝大部分空间本来就是要被新数据覆盖掉的，所以前面绝大部分空间并不需要去费劲反复搬迁数据，只有最后一点点数据收尾的时候需要搬迁，于是在这种情况下就感知不到明显的掉速？

总之楼主不太理解现在的状况……难道同是标注型号为 ST2000LM007 ，还可能有 CMR 而不是 SMR 的盘？楼主感觉这似乎也不太可能吧……

acess

2021-11-27 11:10:41 +08:00

（怎么老是误触回复按钮……尴尬）
CMR 盘也有碎片问题，但是只要整理碎片就能解决。（ drive-managed ） SMR 呢，有个类似闪存上 FTL 的 STL （叠瓦翻译层），那么会不会打破碎片整理依赖的假设，也就是连续的 LBA 对应物理层面上基本连续的写入（之前我有听说硬盘主控可以在出厂时屏蔽少许坏扇区，直接跳过，所以对读写速度几乎没有影响，所谓的“P 表”），于是碎片整理不知道会不会帮倒忙。
啊我现在在 Linux livecd 下，还没注意 Windows 上啥情况，但我记得之前有人说某块 SMR 盘在 Windows 的磁盘碎片整理（改叫“优化”了）里面压根就不显示来着。