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

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

  •  
  •   acess · 54 天前 · 2271 次点击
    这是一个创建于 54 天前的主题,其中的信息可能已经有所发展或是发生改变。
    (先不要吐槽为啥不上固态之类的……)

    想拿到公认是 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 条附言  ·  53 天前
    在 Ubuntu Live USB 环境里跑了测试,开了 LUKS 加密,使用 openssl 的 aes-256-ctr 给每一个文件生成不同的随机数据,而且想了个办法绕开了 openssl 给每个文件生成不同随机数据时的“喘息时间”问题(也就是一边用 dd 从 tmpfs 读取第 N 个文件的随机数据并写入移动硬盘,一边后台让 openssl 在 tmpfs 里生成第 N+1 个文件的随机数据)。
    第一遍把 2T 空间写满,结果跟 Windows+BitLocker 的情况几乎是一样的,看不出有掉速问题。(而且既然这个盘不支持 TRIM ,那么按理说之前 Windows 环境的测试结束后,已经是“脏盘”状态了)
    第二遍我实在不想再写 2T 数据了,每 10 个文件用新密钥生成新的随机数据进行覆写,结果曲线和第一遍几乎是重合的,还是看不出掉速问题。
    第 2 条附言  ·  52 天前
    貌似用 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  
       54 天前
    这里面有系统缓存的影响,我的 2T 硬盘 dd 测速 oflag=dsync 直接就最低速度几十 M/s ,不带 oflag 就带着系统缓存跑直接 160+M/s
    acess
        2
    acess  
    OP
       54 天前
    @Cooky 我用的 cygwin 里的 dd ,加了 conv=notrunc,fdatasync
    acess
        3
    acess  
    OP
       54 天前
    @Cooky 另外任务管理器显示的磁盘写入速度,好像时不时瞥一眼,看上去也没有出现显著的掉速。
    acess
        4
    acess  
    OP
       54 天前
    @Cooky 又看了一下设备属性,删除策略是“快速删除(默认)”,应该是因为盘并没有拆出来,还是 USB 线连着原装的移动硬盘盒。下面的写入缓存之类并没有启用。
    而且即便是缓存也应该只影响突发的少量写入,这样直接写满接近 2T 应该迟早要露原形,毕竟我这边的物理内存大小也比 2TB 小太多太多了。
    geniussoft
        5
    geniussoft  
       54 天前
    要想刺激 SMR ,写 0 是不行的,还是写入真实世界数据吧,要不就写不重复的随机文件。
    acess
        6
    acess  
    OP
       54 天前   ❤️ 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  
       54 天前   ❤️ 1
    @acess 找个 livecd 测吧,cygwin 测毕竟隔着一层
    xinbaqiu
        8
    xinbaqiu  
       54 天前 via iPhone
    我这有两块 st2000lm003
    xinbaqiu
        9
    xinbaqiu  
       54 天前 via iPhone
    楼主有兴趣可以联系我(测试或者购买
    514146235
        10
    514146235  
       54 天前
    smr 硬盘在写的比较满的情况下速度掉的很严重。几乎可以掉到 10M/s 左右,而且还不一定能稳定在这个速度。
    ryd994
        11
    ryd994  
       54 天前 via Android   ❤️ 1
    smr 的问题是磁道有重叠,所以写入大小小于整磁道的时候有写入放大的问题。
    你试来试去都是连续写入,被缓存合并成整磁道了,那当然试不出问题啦。其实 smr 没那么坑,你自己存点电影什么的没影响。
    如果是 zfs 重建这样的,随机写入,而且是大范围长时间的,那 smr 的问题就会暴露出来了。我 nas 上就有两块 smr 盘。平时用没事但是往 smr 空盘上写入重建就会掉到个位数 MB 。可以往 cmr 的氦气盘上重建。然后整盘 dd 到 smr 盘上。
    2i2Re2PLMaDnghL
        12
    2i2Re2PLMaDnghL  
       54 天前   ❤️ 1
    SMR 重点是小量随机覆写容易被写入放大,如果你直接丢一大堆数据的话很可能可以直接被优化掉(已知将被覆写的数据)。
    我怀疑你就算 dd ,bs 调大也能作相同效果
    billgong
        13
    billgong  
       53 天前   ❤️ 1
    我只是在 nas 上用过 SMR ,都是 8T 的希捷。一个是 resync ,另外一个是 dd bs=4M 写入整盘(双盘克隆),必定在 50-80%这个区间掉速到个位数 m/s 。

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

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