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-26 22:12:46 +08:00

@geniussoft
就是为了防止主控发现全是 0 而偷懒，我才开了 BitLocker ，并且指定加密方式为 XTS-AES 128 （而且 manage-bde -on -fet hardware 会报错“不支持基于硬件的加密”）。而且在此之前还是全盘随机填充过一次的。
而且不重复的随机文件我也算试过了（尽管本来就已经是隔着一层 BitLocker 了），跑了大概一两百 GB 吧（不过我是先在 ramdisk 里生成好再写进去，这样会有个短暂“喘息时间”，生成随机数据大约 300 多 MB/s ）……但好像没看出明显掉速。
再然后我就不再给每一个文件重新生成一份新的数据了，直接从 ramdisk 里复制同一份随机数据，这样跑出来和（透过 BitLocker ）写 0 的情况几乎是一模一样的。

也许在 Linux 下测试才能彻底从心理上打消所有疑虑，但我感觉现在这个状况好像不太可能是缓存、主控对写 0 特殊处理之类的。