分享：Synology照样没有解决Btrfs根本缺陷

即使Synology做了有关对抗静默数据损坏的工作，但是Btrfs先天缺陷仍然解决不了。
Btrfs 还是那个 Btrfs。
多树结构、Extent Tree 全局锁、延迟引用、校验和分离、崩溃一致性风险……全都保留
Btrfs 元数据炸了 → mdraid 救不了
比如：
- Extent Tree 损坏
​- 多树不一致
​- 延迟引用死锁
​- 快照引用爆炸
​- 静默损坏检测不到
Btrfs 数据校验和存在 CSUM Tree，这棵树坏 = 所有数据校验失效。
这是架构级缺陷。
ZFS 是块指针内嵌校验 + Merkle 树，任何篡改/损坏都能抓到。
群晖 Btrfs 做不到。
Extent Tree 全局锁瓶颈 → 群晖也绕不过去
所有删除、写入、分配空间，都要过 Extent Tree 全局锁。
这是 Btrfs 最核心的性能瓶颈。
群晖改不了这个结构，所以：
- 大量小文件 → 卡
​- 删大文件夹 → 慢
​- 高并发写入 → 抖动
​- 快照一多 → 更卡
这是架构病，不是优化能救的。
多树一致性风险 → 群晖只能缓解，不能根除
Btrfs 要同时维护 10+ 棵树：
FS Tree、Extent Tree、Chunk Tree、CSUM Tree…
突然断电/崩溃 → 多树不同步
结果：
- 需要 btrfs check
​- 检查极慢
​- 可能修不好
​- 可能丢数据
群晖只能靠 UPS、日志、延迟写来降低概率，不能从架构上消除。
群晖魔改 Btrfs → 只改界面、工具、策略
​Btrfs 架构四大命门依然存在：
​1. 多树复杂，一致性难保证
​2. Extent Tree 全局锁，性能瓶颈
​3. 校验和分离，无法真正端到端完整性
​4. 延迟引用复杂，容易出损坏bug
群晖 Btrfs = 穿了盔甲的 Btrfs，但心脏和骨骼还是原来那个。
真遇到元数据级灾难，该跪还是跪。