这是一个创建于 1256 天前的主题，其中的信息可能已经有所发展或是发生改变。
之前发过一个帖子 /t/629156
于是干脆手上几个空闲 U 盘均实际测试一下了 1-3 号 U 盘在 2020-06-20 写入,4-6 好 U 盘在 2020-06-22 写入,基本上可以认为都静态存放了 1 年,所有文件都是随机生成的一万个 32K 文件,U 盘格式化为 exFAT 格式 校验使用 flashsfv U 盘检测使用 ChipGenius_v4_19_0319
U 盘状态
-
1 号 U 盘:朗科 U195 32G USB 2.0 接口,从缝隙看是个黑色一体封装 U 盘,无法读取主控和闪存型号,这也是唯一一个长期通电使用的 U 盘. 实际上并未撑到 1 年时间,在 2021-01-27 即因正在使用的 key 文件出错(在此之前已经出现 key 文件数量减少的情况),只能重新写入,截至今日,原文件仅存 2391/10000,出错率 18/2391,如果把缺失文件算上,实际上的出错率应该高达 7627/10000
-
2 号 U 盘:宜家沙发形状 U 盘,8G,USB 2.0 接口,主控 Alcor Micro,闪存 SanDisk SDTNPMAHEM-008G - 1CE/Single Channel [MLC-8K] 原本以为这个 U 盘成绩不会特别好,但是实际结果文件完整性 100% 但是,这个 U 盘还存有一份与 6 号 U 盘相同,但是在测试开始之前就已经损坏的文件,这份测试文件由于当时并未做详细记录,在今天出错率为 52/10000,但是由于这个测试文件与 6 号测试文件出错概率并不一样,因此可以断定,这份文件依然产生了损坏,修正后数据为 33/10000
-
3 号 U 盘:金士顿 DTSE9 8G USB2.0 主控 Solid State Systems,闪存 Toshiba TC58TEG6TCKTA00 - 1CE/Single Channel [TLC-8K] 比较古老的一个金士顿低端 U 盘,金属外壳,对成绩不报太大期待,因为在之前的帖子里提到数据损失就是这个型号的 U 盘,不过之前是长期插电,这次是没有插电,实测完整性为 100%
-
4 号 U 盘:东芝 MX 64G USB 3.0 接口,主控 SK6211BB/TC58NC6686G1F 闪存无法读取 东芝出的比较高端的一个 U 盘,写入速度可以达到 100MB/s,测试之前认为这个 U 盘应该毫无问题,实际结果也是如此,完整性 100%
-
5 号 U 盘:夏科 32G USB2.0 接口,主控 FirstChip,闪存 Intel - 1CE/Single Channel [TLC] 薅羊毛 9.9U 盘,金属外壳,有天猫标志,TLC 颗粒基本不太有期待,不过实际结果居然是 100%
-
6 号 U 盘:实际上 6 号并非是 U 盘,而是本机的 SSD.PM981,文件存放在桌面,电脑 7*24 开机,但是在测试期间并未去读取和覆盖过测试文件. 测试文件直接测试结果为 20/10000,但是在 2 号 U 盘中也说明了,这份测试文件本身就是有问题的,经过和 2 号文件交叉对比,修正后数据为 3/10000
结论
其实如果排除掉 2 号和 6 号的存疑,那么我们几乎可以得出,主控芯片明确,闪存芯片没有问题的 U 盘,可以稳定的保存数据至少 1 年而不损坏. 但是鉴于 10000 个文件,总大小也仅为 156M,即使是最小容量的 8G,也仅仅占了很小的一部分,所以似乎这个测试说服力也是不足够的,特别是 2 号 U 盘的状况,2 份测试文件,一份可以通过,一份确损坏了很多 6 号 U 盘也就是 SSD 的测试更是让人担心数据完整性
 |
1
delectate 2021-06-23 18:20:00 +08:00
很多情况下，并非文件没有丢失 or 损坏，只是你不知道。
raid 很重要啊。 tlc 的特性决定，越久没有上电，越容易出问题。slc 还好一点，但是几年不用也会丢数据。 最后，感谢楼主秉承长期主义的测试。 |
 |
2
PhaSelEza 2021-06-23 19:25:09 +08:00
exFAT 可能不太行。备份用的闪迪 CZ80，定期检查时，发现一个写入半年多的文件校验码错误。
现在换了 ReFS，还没出过错，不知道能不能稳定些。 |
 |
3
v2tudnew 2021-06-23 21:03:06 +08:00
不只是 U 盘，HDD 也是如此，就前几个小时我就发现几个文件不见了，还有一个文件夹的权限全没了，不过数据倒是校验通过。
|
 |
4
mm163 2021-06-23 22:11:07 +08:00
赞一下，很少看到这样的测试
|
 |
5
westoy 2021-06-23 22:14:58 +08:00
我现在已经养成日常用 ddrescue 复制文件的习惯了......
|
 |
6
FS1P7dJz OP |
 |
7
Osk 2021-06-23 22:44:53 +08:00
这就是 BtrFS 和 ReFS 等带校验的文件系统的意义了. 不过有一些纠结的地方:
没有镜像 /奇偶校验, 文件坏了就完了. 最过分的是 ReFS, 之前不是有 v2 帖子说 VHDX 被直接删掉(忘了是不是完整性流检测到错误导致的). 其实很多时候一些文件坏个一部分还能用啊... NTFS 不支持完整性流是真的遗憾. |
|
8
Osk 2021-06-23 22:49:20 +08:00
另外, 垃圾的闪存简直是在垃圾堆中捞数据, 之前我对一个垃圾的 SSD 开卡, 结果 ECC bits 如果设置过低, 将导致坏块过多无法开卡, 不知道是不是我理解有误:
开卡检测时, 若单元中错误的位数没有大于设置的 ECC bits, 则认为单元是好的. 我一开始使用 1 bits, 完全开不动... 甚至 SLC 模拟区都一堆坏块, 模拟 SLC 都这样, 真的是稀烂了. 简直就是靠 ECC 算法在捞数据. |
 |
9
SuperMild 2021-06-23 22:50:05 +08:00
几年前听说了文件会静默损坏，从那时开始我就一直在想该如何长期保存文件，想过 raid 也想过云端对象储存（注意低价格的网盘也不防静默损坏），最终的解决方案是自己做了一个本地备份工具 https://github.com/ahui2016/localtags
|
|
10
FS1P7dJz OP |
 |
11
Kagari 2021-06-23 23:17:59 +08:00
可以用 urwtest 填满再测一年
备份后还要校验太麻烦了，普通的云备份校验更加麻烦 |
 |
12
lloovve 2021-06-23 23:24:24 +08:00 via iPhone
千年光盘
|
 |
13
neteroster 2021-06-23 23:50:27 +08:00 via Android
@FS1P7dJz
ZFS 并不是一定要 ECC 内存吧。虽然 ECC 内存确实有额外好处，但是在没有的情况下也能巡检查错，若有冗余则可以恢复。按我的理解，zfs 的巡检并不主要依赖 ECC 内存。 我以前有个移动硬盘，放了一段时间拿出来之后 zfs scrub 就报告了一些文件的错误（电脑没有 ECC 内存）。 |
|
14
SuperMild 2021-06-24 00:13:24 +08:00
@FS1P7dJz 我的方案是个笨办法，记录每个文件的 hash，然后定期检查。另外每个文件至少备份到另一个硬盘中，一旦发现文件损坏（只要不是两个硬盘同时损坏），就可以恢复。
|
 |
15
wttx 2021-06-24 08:38:03 +08:00 via Android
要不看看我设计的盘？纯 u 盘主控基本都没有均衡磨损，ecc 也就那样，再加上 tlc 的漏电情况，丢数据很正常，😂
|
 |
16
hahiru 2021-06-24 09:28:47 +08:00
要不要再测试一下强磁环境下对数据保存的影响？🧐
|
|
18
FS1P7dJz OP @wttx 我其实对性能和容量没有要求,甚至 512M 都够,只要存储稳定...不过你的 U 盘确实是很高兴能和小体积的代表了
|
|
19
FS1P7dJz OP @hahiru 缺少强磁环境啊...另外三星 TF 卡表明可以抗 15000 高斯磁场,是一般核磁共振的磁场强度
而且...众所周知...其实 TF 卡本身并没有什么特殊的抗磁设计,只能说闪存本身就可以抗磁,所以应该可以认为常见的磁场环境对闪存应该没有影响 |
 |
20
celeron533 2021-06-24 12:44:44 +08:00
另外注意温度。温度越高，数据都是概率越大。如果你把颗粒放在汽车里，阳光暴晒，出问题的时间间隔会更短
|
Select Language