RAID5，RAID6因为Write hole问题，写入时故障必然会出现无法修复错误。
硬件RAID卡对此的应对方案是加内存和电池。
软RAID对此是无计可施的。
而Btrfs文件系统正如他的名字，是用B树保存元数据的，这个B树出现问题，会有一大片数据丢失，甚至全部丢失。
所以Btrfs的要求是，元数据要使用RAID 1或其变种，一定不要使用RAID 5， RAID 6这种。
数据部分使用RAID 5， RAID 6时，要经常scrub修错误。
飞牛的方案是mdadm+lvm+Btrfs套娃，不管组什么RAID，都用mdadm组，Btrfs那里永远是单盘。
这导致，Btrfs本身对RAID的措施失效，且如果是RAID 5， RAID 6，Btrfs的元数据实际上还是放在有Write hole问题的RAID 5， RAID 6上，只不过Btrfs认不出来，scrub也无效。
这种套娃方式集百家只所短了属于是。
正儿八经的用法就是直接Btrfs，并且如果要组RAID5， RAID6，那就给元数据单独指定成RAID1或其变种。
PS：
RAID 1也有Write Hole问题，只不过RAID 1可以使用校验和修复，Btrfs的校验和是跟写时复制绑定的，如果禁用了写时复制，RAID 1也是不安全的。
Write Hole的问题简单讲就是，当写入或修改一处数据，对应在物理的硬盘上需要修改多处时，在还没有全部修改完时发生故障，数据会不同步。在没有独立硬件保证的情况下，RAID 5， RAID 6的Write Hole是无解的。
我是八块硬盘组了俩Btrfs的RAID 5，因为下载功能占满了内存，只能强制关机，开机后，运行了一段时间，有一组RAID 5变成了只读，看日志发现是元数据错误了，对两组RAID 5都检查了，都有不少错误，修复的时候发现，Btrfs竟然是套娃单盘的，没法修复了。
PS2：
Bcachefs一定程度上缓解了这个问题，毕竟background，foreground 和 promote对同一处修改在故障时同时数据不同步的概率低了很多。只可以这个文件系统太早期了，而且开发者乱搞，还被移出内核了。
2026-3-13 09:27:01
2026-3-13 10:47:11