21. Btrfs太危险!大家警惕!!太危险!!btrfs的核心级别bug,直到今天依然没有修复。强烈警示大家工作环境不要使用btrfs!如果使用,做好备份。
以下是Linux 内核社区、Btrfs Bugzilla、Arch/Proxmox/Debian 服务端社区针对 mdraid 软阵列 + Btrfs长期挂载只读文件EIO错误的描述:
File can be read/played normally, but cp, mv, rsync fail with EIO
Only happen on long-term mounted btrfs, no write activity on the file for months.
Underlying block device(raid1/raid5/mdraid/hwraid) is completely healthy, ext4 never hit this.
以上描述和图片中的错误一模一样!
文件可正常读取、流畅播放,但使用 cp、mv、rsync 拷贝/移动文件时,会报输入/输出错误 并终止操作。
该问题发生在长期持续挂载的 Btrfs 文件系统上,受影响文件已连续数月无任何写入操作。
底层块存储设备(包含 RAID1、RAID5、raid6、Linux软阵列mdraid、硬件阵列)运行状态完全正常健康,Ext4 文件系统从未出现该类问题。
根本原因不是硬件、不是缓存,就是纯的btrfs 内核错误!
btrfs所有文件依赖根树/extent树/校验和树/文件目录树多层绑定。长期多次 COW、删除、快照、碎片合并、空间回收、缓存页老化,会产生局部树节点引用不一致等问题。
播放时是线性顺序读、只读取数据页、跳过失效的次级元数据分支,只要数据块完好就能解码;
系统调用复制时需要完整遍历 btrfs 目录树、extent映射、元数据节点、校验和,一旦出现损坏的树节点,内核直接返回io错误硬拒绝拷贝,这是内核写死的保护逻辑。
导致的结果就是一个cow文件系统,以checksum作为重要功能,成为了一个必然会导致数据损坏的文件系统。
同时,btrfs的开发者只说会打补丁,而没有任何修复这个bug的时间表。
这个问题可以说btrfs是完全不可用的文件系统,因为你只要用就几乎一定会遇到文件错误。可惜的是在nas领域,需要快照,需要linux的免费授权协议等等原因,导致nas厂家大量采用btrfs。
今天警示大家,请小心谨慎对待btrfs!
我的所有nas文件系统都统一为ext4。#nas #数据 #飞牛nas