从最近发的一个工单来吐槽一下群晖的技术支持和 DSM Raid

以下内容纯主观吐槽，各位看个乐即可，也给双 11 准备买群晖的朋友提供一点 FS 方面的参考。

事情起因是，我把自用的存储从 zfs/ext4 迁移到了 btrfs: Gen10 从 zfs 迁到了 btrfs raid10 ，白群晖从 ext4 切到了 btrfs 。

然后我就开始读 btrfs 的文档。(btrfs 和 zfs 的区别还挺大，这点等我下次摸鱼的时候再开帖子唠

我要吐槽的是:

a. 群晖在销售页面关于 btrfs 如何保护用户数据吹得有点过。zfs/btrfs 实现 self-healing 功能的前提是，数据有热冗余，单凭 checksum 只能检测出 data corruption 但无法修复。而群晖的销售给用户的印象是，他们有黑科技能恢复损坏的数据，但实际上他们只是尽量让 mdadm 和 btrfs 不出问题，至于用户的数据，坏了就坏了，修不了

b. 群晖的技术支持的客服，不知道是水平不行，还是警惕心太强，回复不但笼统，而且敷衍，甚至有时是错的。这个工单中，可能认为我是他们竞争对手的人，来套他们的方案...... 但我只是想知道他们如何保护我的数据。以上情况也不是第一次出现在我提的工单里了

下面贴一下工单对话，主题是 "关于存储池'数据清理'功能可以修复 checksum 异常的数据的疑惑":

看了一下我的设备所使用的存储空间的结构，先用 mdadm 创建 raid1 ，再将映射为 md2 的设备作为 pv 交由 lvm 管理，lvm 在 pv 上创建 vg ，进而创建 lv ，最后把 btrfs 放在 lv 上。

据我所知，btrfs 会记录每个 extent 的 checksum 值用于验证这个 extent 中的数据是否完整。而修复 checksum 有异常的数据需要额外的，具有正常的 checksum 的另一份数据。

比如在 Linux 上 btrfs 默认存储两份 metadata 用于在 metadata 损坏时修复这些损坏的 metadata ，而 data 则只存了一份，所以在这种情况下，如果 data 的 checksum 出现异常则无法修复。

而群晖 btrfs 文件系统中也使用了一样的配置，即，2 份 metadata 和 1 份 data 。所以我的理解是数据清理这个功能只能修复 btrfs 中的 metadata ，而不能修复 data 。是这样的吗？

如果不是的话，数据清理的行为和结果是什么样的？

您对于数据清理中 FS scrubbing 这个部分理解没有问题，但是执行数据清理这个操作会包含两个操作，FS scrubbing 和 RAID scrubbing 。

理论上如果 Btrfs 不开 COW 的话其实并不会知道某个 data 有损坏，只有读到这个文件才会知道文件损坏了。

而当文件系统在进行 FS scrubbing 的时候如果查到某个文档 data 真的坏了，那就会去做 RAID scrubbing 然后用 RAID parity 来修修看（不管有没有开 COW ）。

数据清理如果包含 btrfs scrub & mdadm scrub 两个操作的话，它们的执行逻辑是怎样的？
先 btrfs scrub ，再 mdadm scrub ，这两个步骤一定会按这样的顺序发生？
或者像你说的那样，btrfs scrub 遇到 data checksum 不一致时才发生 mdadm scrub ？

我注意到，对于 mdadm scrub 来说:
1. mdadm raid5/6 在遇到数据不一致时会假定 checksum 错误，然后根据(尽管可能已经损坏的)已有数据重新计算 checksum
2. mdadm raid1 遇到数据不一致时会假定第一个硬盘的数据是正确的，然后覆写到其他的硬盘中
如果发生 data checksum 不一致的情况，那么 mdadm scrub 为什么可以修复 btrfs 中的数据？

按照我的理解来看，mdadm scrub 所更新的数据只是用于构成 mdadm 的数据。mdadm 暴露给 btrfs 的，btrfs 可以看到的数据并没有变化，所以我认为 mdadm scrub 无法修复 btrfs 中 data checksum 不一致的问题。这个推断的过程哪里有问题？

抱歉让您久等了，目前这边有与相关工程师讨论，回复如下：

目前 DSM 在执行数据清理的时候是会先执行 FS scrubbing 再执行 RAID scrubbing ，但由于您当前的许多问题涉及到 Btrfs 的底层原理及行为，由于 Btrfs 是 Oracle 所研发，因此对于此文件系统的具体原理与技术规范的准确解释，我们建议您可以直接查阅或咨询 oracle 官方。

参考： https://docs.oracle.com/en/operating-systems/oracle-linux/8/fsadmin/fsadmin-ManagingtheBtrfsFileSystem.html#btrfs-setup

我不关心 btrfs 的技术细节，我想问的是 DSM 如何保证数据被修复，或者向用户报告数据无法被修复。

btrfs 存储 2 份 metadata 和 1 份 data ，那么 data 损坏时，DSM 所用的 raid(mdadm)又不能保证 data 可以被修复。那么，在这种情况下，一旦数据无法被修复，DSM 会向用户报告拥有这部分 data 的文件损坏，需要用户手动介入？

首先，DSM 本身、Btrfs 文件系统又或是带有冗余功能的 RAID ，都不能完全保证在原始数据错误的情况下数据的完整性。

一般情况下如果数据在文件系统中出现错误，则大概率就已经发生文件系统错误，而文件系统检查都是以修好文件系统本身的结构为主，损坏的文件本身很有可能还是坏的。

因此若您的数据十分重要，Synology 始终建议您备份多个数据副本到不同的地方，以保证数据安全。

参考：如何备份 Synology NAS

关于这句 "首先，DSM 本身、Btrfs 文件系统又或是带有冗余功能的 RAID ，都不能完全保证在原始数据错误的情况下数据的完整性。" 本身就不对。

对于 Btrfs raid1/10 以及不稳定的 btrfs raid5/6 ，又或者是 zfs mirror/raidz 这种有 self-healing 的 fs 来说，在一份 data 损坏的情况下都可以根据 fs 内部的热冗余或 raid 中的奇偶校验码来修复损坏的那份数据。只有当 data 损坏且没有热冗余的情况下 fs 才会报告 data corruption 需要用户介入。

(注意，目前只有 btrfs/zfs 有 self-healing 。mdadm 没有，硬件 raid 也没有。

威联通用的是纯 zfs ，使用 mirror/raidz 的情况下可以触发 self-healing 修复 corrupted data ；或者像我一样自建存储，使用 btrfs raid10 也能让 self-healing 生效。

总之，准备购买群晖的朋友要注意，就我目前阅读的结论来看，群晖，不论采用什么方案都无法保证数据完整性，他们只能尽量保证 DSM 的运行不出问题；就我发了六七个工单的体验来看，对于知识不够丰富的个人用户来说，群晖的技术支持约等于 0 ，对于有服务器运维经验的用户来说，客服的回复多数时候有误导性。

gridsah

2023-10-28 15:22:41 +08:00

@geniussoft #12 补 #15 的内容

#12 只是我阅读群晖这篇文档后的推测。目前我依旧坚持我写在 #10 的判断。

即，群晖先做 fs scrub 再做 raid (mdadm) scrub 的成果是，修复影响 btrfs over lvm over mdadm 这套组合正常运行的问题，而由于 mdadm 暴露给 btrfs 的，btrfs 能看到的数据没有变化，所以 btrfs 不能修复已损坏的数据，最终，用户已损坏的数据保持在已损坏状态。

原因如下。

我试图从 raid.wiki.kernel.org 中验证 mdadm 是否有直接的可供 DSM 使用的，用以获取数据 redundant copy 的方法，以佐证我 #12 的猜测，但是没找到。我只找到了:

https://raid.wiki.kernel.org/index.php/Detecting,_querying_and_testing#Simulating_data_corruption mdadm 并不保证数据完整性
https://raid.wiki.kernel.org/index.php/Scrubbing_the_drives mdadm 检测到 block error 时，对于 raid1 就从第一个盘取数据然后搬到其他盘，对于 raid5/6 就根据现有数据重新计算校验和

-----

如果让我来实现这个获取数据的 redundant copy 的功能的话，我先给一个 raid1 的思路，先从 btrfs 中拿到到已损坏的数据所处的，相对于文件系统起始的位置偏移；再计算 btrfs 所在的 lv 的对于硬盘的物理位置，结合二者可以计算出硬盘什么位置有 block error ，然后去 mdadm raid1 的从盘上对应的位置找到对应位置，利用从盘上的数据计算 checksum 并和 btrfs 中的 checksum 比对，以确定到底是主盘上的数据有问题，还是从盘上的数据有问题，然后修复。

这还是建立在存储池空间连续的情况下。群晖给存储池提供了足够的的灵活性，如果用户先建立数个小存储池 (对应数个 lv)，然后给存储池扩容，这就导致属于每个存储池 (lv) 的空间并不连续，会增加计算难度。

这还没算 SHR+raid1 等其他组合的计算难度和工作量。除了 raid1 还有 raid5/6......

总之，实际操作复杂得多。计算这些数据需要群晖的开发人员对于 mdadm, lvm, btrfs 中数据在硬盘上的的物理分布有深入的理解。而兼容群晖所提供的灵活性也需要大量的开发和测试工作。

**而就我对群晖的主观认知，他们不会投入精力在定制这些基础组件上，所以我判断他们用的是原版的 mdadm 。**

而原版 mdadm 的行为，如文档所说，并不保证数据完整性。

-----

所以 bro 你还有其他可以佐证的文档没有。

( 我最近在读关于群晖如何保证数据完整性的文档，目前我的主观判断是，群晖无法真正保证用户数据的完整性，所以我原定的双十一购买新的群晖的计划也就无了

gridsah

2023-10-28 20:20:37 +08:00

@Damenly1 #36 That's not a btrfs problem. That's a problem about how Synology uses btrfs and mdadm or even how Synology customs btrfs and mdadm. So sending an email to btrfs team will have no help with the problem.

@Rorysky #38 不是数据只存储了一份，是 btrfs 只看见了一份。mdadm+lvm 屏蔽了 btrfs 对于底层存储结构的感知。

@zhughs #39 emmmmm 你举的微软的例子，我这么干过，只不过我问的不是 refs ，是 DFS ，微软的客服教我怎么提 ticket 怎样升级到对应工程师那里，最后，怎么付钱。群晖既然敢把这个东西商用，那就要接受客户的相关提问，或者，回答不了的时候，教客户怎么升级 ticket ，并且收费，而不是强行回答。我都愿意买没什么性价比的白群晖了，愿意付钱。

直白点说，你对于 btrfs 和 mdadm 的存储结构和行为的理解不对。从 '那这个时候就会调用 mdadm 的修复功能' 这里开始错。mdadm 自己的修复功能就像我之前说的那样，mdadm 自己也不知道自己的 raid5 中哪里的数据对，哪里的数据不对，mdadm 所做的只是让 mdadm 可以正常运行下去，而不是修好用户的数据。

至于你后面所描述的修复行为，mdadm 没有这样的功能，btrfs 也没有。要有那就只能是群晖自己做的，而就我对于这个功能的工作量的估计与对群晖的了解来看，群晖没有能力对底层做这样的改动。 *注意，这句是我的主观判断。*

'而又由于 btrfs 文件系统的 checksum 是在 metadata 里的会存两份，所以文件的 checksum 出错概率会相对比较低。'

并不是 checksum 在 metadata 里存两份，而是每一个 data extent 有存有自己的校验和，metadata 也有自己的校验和，然后默认情况下硬盘中有两份一模一样的 metadata ，所以可以做到 metadata 的 self-healing ，而 data extent 只有一份，所以无法触发 self-healing 。