关于硬盘的 URE（Non-recoverable read errors per bits read）错误以及 FastCopy 的验证功能

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

请不要把任何和邀请码有关的内容发到 NAS 节点。

邀请码相关的内容请使用 /go/in 节点。

如果没有发送到 /go/in，那么会被移动到 /go/pointless 同时账号会被降权。如果持续触发这样的移动，会导致账号被禁用。

这是一个创建于 2180 天前的主题，其中的信息可能已经有所发展或是发生改变。

前两天 NAS 炸了，于是各种看资料，发现硬盘有个 URE 错误率的指标，了解这个指标以后从此再也不用 RAID5 了……
那么关于 URE 有个问题想请教一下大家，就是如果和 RAID5 没关系，只是在普通的复制数据，应该也是有可能碰到 URE 错误的吧。看描述好像这种错误硬盘自己不知道，那假如在复制的时候真的遇见了，是不是可以理解为写入目标盘的某个 bit 是错的？如果存在这种情况的话，那 FastCopy 的验证功能是否能够避免？
FastCopy 帮助文档里是这么描述验证工作流的：
Action detail: Read(Src) -> MD5(Src) -> Write(Dst) -> Read(Dst) -> MD5(Dst) -> Compare MD5(Src/Dst) (All actions are processed in parallel as much as possible)
它读源文件和算 Hash 好像是同时进行的，那么是不是可以理解为，如果硬盘读错了，他也就跟着拿错误的源数据做 Hash，然后把错误的源数据写入目标盘，再读一遍目标盘有错误的数据计算 Hash 做对比？如果是这样的话，是不是它并不能避免 URE 错误带来的影响？

ure

dst

错误

read

8 条回复 • 2018-12-05 11:23:08 +08:00

ryd994

2018-12-04 01:23:40 +08:00 via Android

从你说的流程来说，不能
这个问题 zfs 可解

Osk

2018-12-04 01:52:41 +08:00 via Android

我觉得不能，最起码它可能受操作系统缓存的影响。主要是读取的文件本身可能就坏的。

btrfs raid 1 应该能解决这个问题：从磁盘读文件，计算 crc/hash，如果不一致，从 raid 镜像中尝试读取并校验，直到得到完整数据，否则 io error。btrfs 也支持 scrub，读取所有已有数据，利用 raid1 镜像和 crc 自动检测并修正写入不正确的数据或损坏的数据，两块盘只要不是同时坏同样位置的扇区应该都能抢救下。btrfs raid5 目前还不能用，有 bug。

vempx

2018-12-04 08:28:17 +08:00

@Osk 那意思是说，极端情况下，NTFS 也好 EXT4 也好这个毛病都无解了？

whileFalse

2018-12-04 08:43:54 +08:00

我记得扇区是有校验和的。理论上读出错数据是会重读的。

vempx

2018-12-04 09:46:24 +08:00

@whileFalse 这个 URE 错误好像是校验和也无法发现的，似乎就是硬盘根本无法得知自己读错了。

gamexg

2018-12-04 09:51:16 +08:00

微软的 ReFS 也可解决这个问题。
但是单盘就好别用这个，Refs 再碰到不可修复错误时直接删除出错文件来解决这个错误。

vempx

2018-12-04 10:04:44 +08:00

emmmmmm
群晖的系统是用 LVM 组的 RAID，然后再上面再跑 btrfs。
虽说原生 btrfs RAID5 有 bug，但是原生的 btrfs RAID1 应该是没问题的，不知道群晖里面怎么用原生 btrfs RAID1

Osk

2018-12-05 11:23:08 +08:00 via Android

@vempx 是啊，好像这两种 fs 都是没有校验码的，读出来的文件坏了就是坏了，关键是还不知道它坏了