V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
acess
V2EX  ›  硬件

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

  •  
  •   acess · 2021-11-26 21:24:28 +08:00 · 4572 次点击
    这是一个创建于 853 天前的主题,其中的信息可能已经有所发展或是发生改变。
    (先不要吐槽为啥不上固态之类的……)

    想拿到公认是 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 的盘?楼主感觉这似乎也不太可能吧……
    第 1 条附言  ·  2021-11-27 15:29:17 +08:00
    在 Ubuntu Live USB 环境里跑了测试,开了 LUKS 加密,使用 openssl 的 aes-256-ctr 给每一个文件生成不同的随机数据,而且想了个办法绕开了 openssl 给每个文件生成不同随机数据时的“喘息时间”问题(也就是一边用 dd 从 tmpfs 读取第 N 个文件的随机数据并写入移动硬盘,一边后台让 openssl 在 tmpfs 里生成第 N+1 个文件的随机数据)。
    第一遍把 2T 空间写满,结果跟 Windows+BitLocker 的情况几乎是一样的,看不出有掉速问题。(而且既然这个盘不支持 TRIM ,那么按理说之前 Windows 环境的测试结束后,已经是“脏盘”状态了)
    第二遍我实在不想再写 2T 数据了,每 10 个文件用新密钥生成新的随机数据进行覆写,结果曲线和第一遍几乎是重合的,还是看不出掉速问题。
    第 2 条附言  ·  2021-11-28 03:38:25 +08:00
    貌似用 iometer 跑出来掉速的效果了。
    在磁盘空间末尾分一个略大于 128G 的区,设置单次写入大小 1MiB 、100%随机( 0%顺序)、100%写入( 0%读取)、测试文件总大小 128GiB ( maximum disk size 设为对应的扇区数),再多预热十几分钟,就能跑出来写入速度大约 2MB/s 、平均寻道时间( average I/O response time )大约 500 多 ms 的结果了。不过跑到后面貌似有点奇怪,任务管理器显示写入速度只有 2MB/s ,iometer 里似乎各项指标又变得比这个数据快一倍(包括平均寻道时间)。
    33 条回复    2021-11-29 18:59:09 +08:00
    Cooky
        1
    Cooky  
       2021-11-26 21:37:48 +08:00
    这里面有系统缓存的影响,我的 2T 硬盘 dd 测速 oflag=dsync 直接就最低速度几十 M/s ,不带 oflag 就带着系统缓存跑直接 160+M/s
    acess
        2
    acess  
    OP
       2021-11-26 21:42:27 +08:00
    @Cooky 我用的 cygwin 里的 dd ,加了 conv=notrunc,fdatasync
    acess
        3
    acess  
    OP
       2021-11-26 21:44:33 +08:00
    @Cooky 另外任务管理器显示的磁盘写入速度,好像时不时瞥一眼,看上去也没有出现显著的掉速。
    acess
        4
    acess  
    OP
       2021-11-26 21:55:57 +08:00
    @Cooky 又看了一下设备属性,删除策略是“快速删除(默认)”,应该是因为盘并没有拆出来,还是 USB 线连着原装的移动硬盘盒。下面的写入缓存之类并没有启用。
    而且即便是缓存也应该只影响突发的少量写入,这样直接写满接近 2T 应该迟早要露原形,毕竟我这边的物理内存大小也比 2TB 小太多太多了。
    geniussoft
        5
    geniussoft  
       2021-11-26 21:59:21 +08:00
    要想刺激 SMR ,写 0 是不行的,还是写入真实世界数据吧,要不就写不重复的随机文件。
    acess
        6
    acess  
    OP
       2021-11-26 22:12:46 +08:00   ❤️ 2
    @geniussoft
    就是为了防止主控发现全是 0 而偷懒,我才开了 BitLocker ,并且指定加密方式为 XTS-AES 128 (而且 manage-bde -on -fet hardware 会报错“不支持基于硬件的加密”)。而且在此之前还是全盘随机填充过一次的。
    而且不重复的随机文件我也算试过了(尽管本来就已经是隔着一层 BitLocker 了),跑了大概一两百 GB 吧(不过我是先在 ramdisk 里生成好再写进去,这样会有个短暂“喘息时间”,生成随机数据大约 300 多 MB/s )……但好像没看出明显掉速。
    再然后我就不再给每一个文件重新生成一份新的数据了,直接从 ramdisk 里复制同一份随机数据,这样跑出来和(透过 BitLocker )写 0 的情况几乎是一模一样的。

    也许在 Linux 下测试才能彻底从心理上打消所有疑虑,但我感觉现在这个状况好像不太可能是缓存、主控对写 0 特殊处理之类的。
    Cooky
        7
    Cooky  
       2021-11-26 22:19:57 +08:00   ❤️ 1
    @acess 找个 livecd 测吧,cygwin 测毕竟隔着一层
    xinbaqiu
        8
    xinbaqiu  
       2021-11-26 22:21:25 +08:00 via iPhone
    我这有两块 st2000lm003
    xinbaqiu
        9
    xinbaqiu  
       2021-11-26 22:24:08 +08:00 via iPhone
    楼主有兴趣可以联系我(测试或者购买
    514146235
        10
    514146235  
       2021-11-26 23:36:02 +08:00
    smr 硬盘在写的比较满的情况下速度掉的很严重。几乎可以掉到 10M/s 左右,而且还不一定能稳定在这个速度。
    ryd994
        11
    ryd994  
       2021-11-27 02:38:08 +08:00 via Android   ❤️ 1
    smr 的问题是磁道有重叠,所以写入大小小于整磁道的时候有写入放大的问题。
    你试来试去都是连续写入,被缓存合并成整磁道了,那当然试不出问题啦。其实 smr 没那么坑,你自己存点电影什么的没影响。
    如果是 zfs 重建这样的,随机写入,而且是大范围长时间的,那 smr 的问题就会暴露出来了。我 nas 上就有两块 smr 盘。平时用没事但是往 smr 空盘上写入重建就会掉到个位数 MB 。可以往 cmr 的氦气盘上重建。然后整盘 dd 到 smr 盘上。
    2i2Re2PLMaDnghL
        12
    2i2Re2PLMaDnghL  
       2021-11-27 03:05:59 +08:00   ❤️ 2
    SMR 重点是小量随机覆写容易被写入放大,如果你直接丢一大堆数据的话很可能可以直接被优化掉(已知将被覆写的数据)。
    我怀疑你就算 dd ,bs 调大也能作相同效果
    billgong
        13
    billgong  
       2021-11-27 06:12:25 +08:00   ❤️ 1
    我只是在 nas 上用过 SMR ,都是 8T 的希捷。一个是 resync ,另外一个是 dd bs=4M 写入整盘(双盘克隆),必定在 50-80%这个区间掉速到个位数 m/s 。

    楼上说了其中的原理了,和那些 QLC 掉速差不多的原因。写满了缓存爆了性能自然就下来了。其实平常用起来没什么问题。NAS 不推荐用就是因为换盘后 resync 要老命了。
    kokutou
        14
    kokutou  
       2021-11-27 08:23:01 +08:00 via Android
    持续顺序读写没影响的。
    快满的时候,盘上剩余空间里到处都是脏数据碎片的时候才会变慢。
    codingadog
        15
    codingadog  
       2021-11-27 09:29:54 +08:00
    写一堆大大小小的文件写满,然后随机删掉一半。
    然后再写满,再删掉一半。
    然后就能出来了。。。
    Seanfuck
        16
    Seanfuck  
       2021-11-27 09:57:31 +08:00
    2.5 寸的 cmr 貌似只能买到最大 1T 的了,400 多。
    acess
        17
    acess  
    OP
       2021-11-27 11:00:42 +08:00 via Android
    @billgong 我是 dd bs=1M
    感觉很奇怪。网上说 DM-SMR 用户直接写的是 Media cache
    acess
        18
    acess  
    OP
       2021-11-27 11:03:21 +08:00 via Android
    @billgong (接上条,刚刚手滑按到回复按钮了)
    那么我这样测试应该能看到 media cache 被写满后的断崖式掉速才对。
    那么也许是像我一开始脑补的那样,主控很聪明,知道我是大量顺序写入,于是就直接朝 SMR 里写,这样只需要处理最后一点点收尾的(因邻近磁轨会被覆写而不得不进行的)搬运就 OK ?
    acess
        19
    acess  
    OP
       2021-11-27 11:04:29 +08:00 via Android
    @ryd994
    @2i2Re2PLMaDnghL
    所以并不单纯是“脏盘掉速”,其实是“碎片掉速”?
    acess
        20
    acess  
    OP
       2021-11-27 11:04:56 +08:00 via Android
    @ryd994
    @2i2Re2PLMaDnghL
    所以就有一个问题,
    acess
        21
    acess  
    OP
       2021-11-27 11:10:41 +08:00 via Android
    (怎么老是误触回复按钮……尴尬)
    CMR 盘也有碎片问题,但是只要整理碎片就能解决。( drive-managed ) SMR 呢,有个类似闪存上 FTL 的 STL (叠瓦翻译层),那么会不会打破碎片整理依赖的假设,也就是连续的 LBA 对应物理层面上基本连续的写入(之前我有听说硬盘主控可以在出厂时屏蔽少许坏扇区,直接跳过,所以对读写速度几乎没有影响,所谓的“P 表”),于是碎片整理不知道会不会帮倒忙。
    啊我现在在 Linux livecd 下,还没注意 Windows 上啥情况,但我记得之前有人说某块 SMR 盘在 Windows 的磁盘碎片整理(改叫“优化”了)里面压根就不显示来着。
    20015jjw
        22
    20015jjw  
       2021-11-27 11:26:18 +08:00
    路过
    当时没记错是 raid 重构的时候速度缓慢?
    wanguorui123
        23
    wanguorui123  
       2021-11-27 14:40:42 +08:00
    大概率剩余空间不足时会开始启动叠瓦写
    wtdd
        24
    wtdd  
       2021-11-27 15:08:52 +08:00
    1GB 还是相同大文件当然不行,差不多装满细碎小文件,然后反复操作几次就看出来了
    acess
        25
    acess  
    OP
       2021-11-27 15:31:53 +08:00
    @wanguorui123 @wtdd 最开始的时候我用 diskgenius 全盘填充过一遍随机数据,而且这盘不支持 TRIM ,更何况我还开了 BitLocker/LUKS 全盘加密,按理说主控压根就不知道哪里是剩余空间。
    geniussoft
        26
    geniussoft  
       2021-11-27 22:00:54 +08:00
    就怕最后发现手头这只根本不是叠瓦...

    2.5 寸何不试试 5TB ,肯定叠瓦🐶
    acess
        27
    acess  
    OP
       2021-11-27 22:18:43 +08:00
    @geniussoft 我也希望这样啊,但我还是觉得这就是 too good to be true 了😂
    另外单单是 ST2000LM007 其实也分不同固件版本来着,貌似新的支持 TRIM 、老的不支持,而且有的老固件能升级、有的老固件升不了:
    https://club.lenovo.com.cn/forum.php?mod=viewthread&tid=5974555
    acess
        28
    acess  
    OP
       2021-11-27 22:38:16 +08:00
    @20015jjw 貌似因为这个问题,西数还被集体诉讼了,最后被判赔偿消费者,不过我感觉这大概还是毛毛雨,对他们的行为不会有多少改变,据说因为这个事情硬盘厂商开始公布 CMR/SMR 的信息,但我印象里公布得并不全。
    aioroscheng
        29
    aioroscheng  
       2021-11-29 08:46:36 +08:00
    @acess 借楼问一下,我有个叠瓦的移动硬盘,备份照片用的,照片文件 jpg 的话 10M 左右,raw 的 20-30M 左右,大概每隔一周会拷贝一次进去,总的文件在 3-8G 不等,请问下大家,这样的使用频率和文件大小,会不会影响到硬盘的性能呢,谢谢
    tubimasky
        30
    tubimasky  
       2021-11-29 11:02:50 +08:00
    我在 tb 475 买的 三星同型号
    acess
        31
    acess  
    OP
       2021-11-29 12:53:04 +08:00
    @aioroscheng 我也没长期使用过叠瓦盘,不太清楚。
    aioroscheng
        32
    aioroscheng  
       2021-11-29 16:45:47 +08:00
    @acess 好的,谢谢,现在要买 2.5 的非叠瓦盘也很难了
    windias
        33
    windias  
       2021-11-29 18:59:09 +08:00
    smr 刚出时候 thw 做过测试,先写满,然后删多个零散文件,再写入,smr 就废了
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   963 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 29ms · UTC 21:54 · PVG 05:54 · LAX 14:54 · JFK 17:54
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.