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

[acess]

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

想拿到公认是 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 的盘？楼主感觉这似乎也不太可能吧……

在 Ubuntu Live USB 环境里跑了测试，开了 LUKS 加密，使用 openssl 的 aes-256-ctr 给每一个文件生成不同的随机数据，而且想了个办法绕开了 openssl 给每个文件生成不同随机数据时的“喘息时间”问题（也就是一边用 dd 从 tmpfs 读取第 N 个文件的随机数据并写入移动硬盘，一边后台让 openssl 在 tmpfs 里生成第 N+1 个文件的随机数据）。
第一遍把 2T 空间写满，结果跟 Windows+BitLocker 的情况几乎是一样的，看不出有掉速问题。（而且既然这个盘不支持 TRIM ，那么按理说之前 Windows 环境的测试结束后，已经是“脏盘”状态了）
第二遍我实在不想再写 2T 数据了，每 10 个文件用新密钥生成新的随机数据进行覆写，结果曲线和第一遍几乎是重合的，还是看不出掉速问题。

貌似用 iometer 跑出来掉速的效果了。
在磁盘空间末尾分一个略大于 128G 的区，设置单次写入大小 1MiB 、100%随机（ 0%顺序）、100%写入（ 0%读取）、测试文件总大小 128GiB （ maximum disk size 设为对应的扇区数），再多预热十几分钟，就能跑出来写入速度大约 2MB/s 、平均寻道时间（ average I/O response time ）大约 500 多 ms 的结果了。不过跑到后面貌似有点奇怪，任务管理器显示写入速度只有 2MB/s ，iometer 里似乎各项指标又变得比这个数据快一倍（包括平均寻道时间）。

[Cooky]

这里面有系统缓存的影响，我的 2T 硬盘 dd 测速 oflag=dsync 直接就最低速度几十 M/s ，不带 oflag 就带着系统缓存跑直接 160+M/s

[acess]

@Cooky 我用的 cygwin 里的 dd ，加了 conv=notrunc,fdatasync

[acess]

@Cooky 另外任务管理器显示的磁盘写入速度，好像时不时瞥一眼，看上去也没有出现显著的掉速。

[acess]

@Cooky 又看了一下设备属性，删除策略是“快速删除(默认)”，应该是因为盘并没有拆出来，还是 USB 线连着原装的移动硬盘盒。下面的写入缓存之类并没有启用。
而且即便是缓存也应该只影响突发的少量写入，这样直接写满接近 2T 应该迟早要露原形，毕竟我这边的物理内存大小也比 2TB 小太多太多了。

[geniussoft]

要想刺激 SMR ，写 0 是不行的，还是写入真实世界数据吧，要不就写不重复的随机文件。

[acess]

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

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

[Cooky]

@acess 找个 livecd 测吧，cygwin 测毕竟隔着一层

[xinbaqiu]

我这有两块 st2000lm003

[xinbaqiu]

楼主有兴趣可以联系我（测试或者购买

[514146235]

smr 硬盘在写的比较满的情况下速度掉的很严重。几乎可以掉到 10M/s 左右，而且还不一定能稳定在这个速度。

[ryd994]

smr 的问题是磁道有重叠，所以写入大小小于整磁道的时候有写入放大的问题。
你试来试去都是连续写入，被缓存合并成整磁道了，那当然试不出问题啦。其实 smr 没那么坑，你自己存点电影什么的没影响。
如果是 zfs 重建这样的，随机写入，而且是大范围长时间的，那 smr 的问题就会暴露出来了。我 nas 上就有两块 smr 盘。平时用没事但是往 smr 空盘上写入重建就会掉到个位数 MB 。可以往 cmr 的氦气盘上重建。然后整盘 dd 到 smr 盘上。

[2i2Re2PLMaDnghL]

SMR 重点是小量随机覆写容易被写入放大，如果你直接丢一大堆数据的话很可能可以直接被优化掉（已知将被覆写的数据）。
我怀疑你就算 dd ，bs 调大也能作相同效果

[billgong]

我只是在 nas 上用过 SMR ，都是 8T 的希捷。一个是 resync ，另外一个是 dd bs=4M 写入整盘（双盘克隆），必定在 50-80%这个区间掉速到个位数 m/s 。

楼上说了其中的原理了，和那些 QLC 掉速差不多的原因。写满了缓存爆了性能自然就下来了。其实平常用起来没什么问题。NAS 不推荐用就是因为换盘后 resync 要老命了。

[kokutou]

持续顺序读写没影响的。
快满的时候，盘上剩余空间里到处都是脏数据碎片的时候才会变慢。

[codingadog]

写一堆大大小小的文件写满，然后随机删掉一半。
然后再写满，再删掉一半。
然后就能出来了。。。

[Seanfuck]

2.5 寸的 cmr 貌似只能买到最大 1T 的了，400 多。

[acess]

@billgong 我是 dd bs=1M
感觉很奇怪。网上说 DM-SMR 用户直接写的是 Media cache

[acess]

@billgong （接上条，刚刚手滑按到回复按钮了）
那么我这样测试应该能看到 media cache 被写满后的断崖式掉速才对。
那么也许是像我一开始脑补的那样，主控很聪明，知道我是大量顺序写入，于是就直接朝 SMR 里写，这样只需要处理最后一点点收尾的（因邻近磁轨会被覆写而不得不进行的）搬运就 OK ？

[acess]

@ryd994
@2i2Re2PLMaDnghL
所以并不单纯是“脏盘掉速”，其实是“碎片掉速”？

[acess]

@ryd994
@2i2Re2PLMaDnghL
所以就有一个问题，

[acess]

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

[20015jjw]

路过
当时没记错是 raid 重构的时候速度缓慢？

[wanguorui123]

大概率剩余空间不足时会开始启动叠瓦写

[wtdd]

1GB 还是相同大文件当然不行，差不多装满细碎小文件，然后反复操作几次就看出来了

[acess]

@wanguorui123 @wtdd 最开始的时候我用 diskgenius 全盘填充过一遍随机数据，而且这盘不支持 TRIM ，更何况我还开了 BitLocker/LUKS 全盘加密，按理说主控压根就不知道哪里是剩余空间。

[geniussoft]

就怕最后发现手头这只根本不是叠瓦...

2.5 寸何不试试 5TB ，肯定叠瓦🐶

[acess]

@geniussoft 我也希望这样啊，但我还是觉得这就是 too good to be true 了😂
另外单单是 ST2000LM007 其实也分不同固件版本来着，貌似新的支持 TRIM 、老的不支持，而且有的老固件能升级、有的老固件升不了：
https://club.lenovo.com.cn/forum.php?mod=viewthread&tid=5974555

[acess]

@20015jjw 貌似因为这个问题，西数还被集体诉讼了，最后被判赔偿消费者，不过我感觉这大概还是毛毛雨，对他们的行为不会有多少改变，据说因为这个事情硬盘厂商开始公布 CMR/SMR 的信息，但我印象里公布得并不全。

[aioroscheng]

@acess 借楼问一下，我有个叠瓦的移动硬盘，备份照片用的，照片文件 jpg 的话 10M 左右，raw 的 20-30M 左右，大概每隔一周会拷贝一次进去，总的文件在 3-8G 不等，请问下大家，这样的使用频率和文件大小，会不会影响到硬盘的性能呢，谢谢

[tubimasky]

我在 tb 475 买的 三星同型号

[acess]

@aioroscheng 我也没长期使用过叠瓦盘，不太清楚。

[aioroscheng]

@acess 好的，谢谢，现在要买 2.5 的非叠瓦盘也很难了

[windias]

smr 刚出时候 thw 做过测试，先写满，然后删多个零散文件，再写入，smr 就废了