
1 Cooky 2021 年 11 月 26 日 这里面有系统缓存的影响,我的 2T 硬盘 dd 测速 oflag=dsync 直接就最低速度几十 M/s ,不带 oflag 就带着系统缓存跑直接 160+M/s |
4 acess OP @Cooky 又看了一下设备属性,删除策略是“快速删除(默认)”,应该是因为盘并没有拆出来,还是 USB 线连着原装的移动硬盘盒。下面的写入缓存之类并没有启用。 而且即便是缓存也应该只影响突发的少量写入,这样直接写满接近 2T 应该迟早要露原形,毕竟我这边的物理内存大小也比 2TB 小太多太多了。 |
5 geniussoft 2021 年 11 月 26 日 要想刺激 SMR ,写 0 是不行的,还是写入真实世界数据吧,要不就写不重复的随机文件。 |
6 acess OP @geniussoft 就是为了防止主控发现全是 0 而偷懒,我才开了 BitLocker ,并且指定加密方式为 XTS-AES 128 (而且 manage-bde -on -fet hardware 会报错“不支持基于硬件的加密”)。而且在此之前还是全盘随机填充过一次的。 而且不重复的随机文件我也算试过了(尽管本来就已经是隔着一层 BitLocker 了),跑了大概一两百 GB 吧(不过我是先在 ramdisk 里生成好再写进去,这样会有个短暂“喘息时间”,生成随机数据大约 300 多 MB/s )……但好像没看出明显掉速。 再然后我就不再给每一个文件重新生成一份新的数据了,直接从 ramdisk 里复制同一份随机数据,这样跑出来和(透过 BitLocker )写 0 的情况几乎是一模一样的。 也许在 Linux 下测试才能彻底从心理上打消所有疑虑,但我感觉现在这个状况好像不太可能是缓存、主控对写 0 特殊处理之类的。 |
8 xinbaqiu 2021 年 11 月 26 日 via iPhone 我这有两块 st2000lm003 |
9 xinbaqiu 2021 年 11 月 26 日 via iPhone 楼主有兴趣可以联系我(测试或者购买 |
10 514146235 2021 年 11 月 26 日 smr 硬盘在写的比较满的情况下速度掉的很严重。几乎可以掉到 10M/s 左右,而且还不一定能稳定在这个速度。 |
11 ryd994 2021 年 11 月 27 日 via Android smr 的问题是磁道有重叠,所以写入大小小于整磁道的时候有写入放大的问题。 你试来试去都是连续写入,被缓存合并成整磁道了,那当然试不出问题啦。其实 smr 没那么坑,你自己存点电影什么的没影响。 如果是 zfs 重建这样的,随机写入,而且是大范围长时间的,那 smr 的问题就会暴露出来了。我 nas 上就有两块 smr 盘。平时用没事但是往 smr 空盘上写入重建就会掉到个位数 MB 。可以往 cmr 的氦气盘上重建。然后整盘 dd 到 smr 盘上。 |
12 2i2Re2PLMaDnghL 2021 年 11 月 27 日 SMR 重点是小量随机覆写容易被写入放大,如果你直接丢一大堆数据的话很可能可以直接被优化掉(已知将被覆写的数据)。 我怀疑你就算 dd ,bs 调大也能作相同效果 |
13 billgong 2021 年 11 月 27 日 我只是在 nas 上用过 SMR ,都是 8T 的希捷。一个是 resync ,另外一个是 dd bs=4M 写入整盘(双盘克隆),必定在 50-80%这个区间掉速到个位数 m/s 。 楼上说了其中的原理了,和那些 QLC 掉速差不多的原因。写满了缓存爆了性能自然就下来了。其实平常用起来没什么问题。NAS 不推荐用就是因为换盘后 resync 要老命了。 |
14 kokutou 2021 年 11 月 27 日 via Android 持续顺序读写没影响的。 快满的时候,盘上剩余空间里到处都是脏数据碎片的时候才会变慢。 |
15 Duolingo 2021 年 11 月 27 日 写一堆大大小小的文件写满,然后随机删掉一半。 然后再写满,再删掉一半。 然后就能出来了。。。 |
16 Seanfuck 2021 年 11 月 27 日 2.5 寸的 cmr 貌似只能买到最大 1T 的了,400 多。 |
18 acess OP @billgong (接上条,刚刚手滑按到回复按钮了) 那么我这样测试应该能看到 media cache 被写满后的断崖式掉速才对。 那么也许是像我一开始脑补的那样,主控很聪明,知道我是大量顺序写入,于是就直接朝 SMR 里写,这样只需要处理最后一点点收尾的(因邻近磁轨会被覆写而不得不进行的)搬运就 OK ? |
19 acess OP |
20 acess OP |
21 acess OP (怎么老是误触回复按钮……尴尬) CMR 盘也有碎片问题,但是只要整理碎片就能解决。( drive-managed ) SMR 呢,有个类似闪存上 FTL 的 STL (叠瓦翻译层),那么会不会打破碎片整理依赖的假设,也就是连续的 LBA 对应物理层面上基本连续的写入(之前我有听说硬盘主控可以在出厂时屏蔽少许坏扇区,直接跳过,所以对读写速度几乎没有影响,所谓的“P 表”),于是碎片整理不知道会不会帮倒忙。 啊我现在在 Linux livecd 下,还没注意 Windows 上啥情况,但我记得之前有人说某块 SMR 盘在 Windows 的磁盘碎片整理(改叫“优化”了)里面压根就不显示来着。 |
22 20015jjw 2021 年 11 月 27 日 路过 当时没记错是 raid 重构的时候速度缓慢? |
23 wanguorui123 2021 年 11 月 27 日 大概率剩余空间不足时会开始启动叠瓦写 |
24 wtdd 2021 年 11 月 27 日 1GB 还是相同大文件当然不行,差不多装满细碎小文件,然后反复操作几次就看出来了 |
25 acess OP @wanguorui123 @wtdd 最开始的时候我用 diskgenius 全盘填充过一遍随机数据,而且这盘不支持 TRIM ,更何况我还开了 BitLocker/LUKS 全盘加密,按理说主控压根就不知道哪里是剩余空间。 |
26 geniussoft 2021 年 11 月 27 日 就怕最后发现手头这只根本不是叠瓦... 2.5 寸何不试试 5TB ,肯定叠瓦 |
27 acess OP @geniussoft 我也希望这样啊,但我还是觉得这就是 too good to be true 了 另外单单是 ST2000LM007 其实也分不同固件版本来着,貌似新的支持 TRIM 、老的不支持,而且有的老固件能升级、有的老固件升不了: https://club.lenovo.com.cn/forum.php?mod=viewthread&tid=5974555 |
28 acess OP @20015jjw 貌似因为这个问题,西数还被集体诉讼了,最后被判赔偿消费者,不过我感觉这大概还是毛毛雨,对他们的行为不会有多少改变,据说因为这个事情硬盘厂商开始公布 CMR/SMR 的信息,但我印象里公布得并不全。 |
29 aioroscheng 2021 年 11 月 29 日 @acess 借楼问一下,我有个叠瓦的移动硬盘,备份照片用的,照片文件 jpg 的话 10M 左右,raw 的 20-30M 左右,大概每隔一周会拷贝一次进去,总的文件在 3-8G 不等,请问下大家,这样的使用频率和文件大小,会不会影响到硬盘的性能呢,谢谢 |
30 tubimasky 2021 年 11 月 29 日 我在 tb 475 买的 三星同型号 |
31 acess OP @aioroscheng 我也没长期使用过叠瓦盘,不太清楚。 |
32 aioroscheng 2021 年 11 月 29 日 @acess 好的,谢谢,现在要买 2.5 的非叠瓦盘也很难了 |
33 windias 2021 年 11 月 29 日 smr 刚出时候 thw 做过测试,先写满,然后删多个零散文件,再写入,smr 就废了 |