@zhughs #43 说白了，我就是想知道群晖如何处理 silent data corruption......

关于第二点，文件的逻辑位置转硬盘物理位置，组合数据之后重新计算 checksum 的这个功能，在 #23 我估了一下这个功能的工作量，很大，不论是对 madm, btrfs 还是对 DSM 底层的魔改，工作量都很大。我觉得群晖不大可能费力气做这个功能。

我在 存储池 -> 全局设置 里面找到了这个功能。关于这个功能，我只在 https://www.reddit.com/r/synology/comments/qy51ba/what_the_heck_is_fast_repair/?rdt=53246 看到了关于这个功能的猜测，还未被证实。如果帖子里的描述是真的的话，那说不准群晖还真的做了这个功能。

但从回帖的内容来看，我和这帮老外的想法一样，群晖不会花大功夫来研究和定制底层。

而且我认为我的看法是对的，因为，从我这个角度来看，至少他们在升级组件的时候不会有额外的，因兼容群晖自己的魔改而产生的额外的工作量；而且不魔改组件也意味着，不会受人事的限制，不用担心会魔改的员工走了以后没人接活儿的问题。

@zhughs #43 关于第二点 '提供 mdadm 的 fast repair 功能' 这个有链接或者出处吗，我想看看

第三点，我看 btrfs 文档说的是 The whole metadata block has a checksum stored inline in the b-tree node header, each data block has a detached checksum stored in the checksum tree.

按照你的理解方式: 文档逗号以前的意思是，metadata extent 有一个和 metadata 数据存储在一起的 checksum 。data block has a detached checksum stored in the checksum tree 的意思是所有的数据的 checksum ，不论是 metadata 还是 data ，都存储在一个共用的 checksum tree 里面，所以 metadata 的 checksum 有两份。

但是，文档里说，metadata 也有两份，如果按照你这个思路继续推，两份 metadata 有两份跟随 metadata extent 的 checksum ，然后 checksum tree 里还有一份 metadata 的 checksum ，那这不就有三份 metadata 的 checksum 了吗。

所以我认为，文档中逗号以前的意思是，metadata extent 有一个和 metadata 数据存储在一起的 checksum ，不变。但是 metadata 有两份，因此 metadata 的 checksum 有两份。data block has a detached checksum stored in the checksum tree 的意思是所有的 data extent (不包括 metadata extent) 的 checksum 存储在一个独立的 checksum tree 中。所以 data extent 有一份数据 (一个 data extent tree) 和一份 checksum (一个 checksum tree)。

emmmmm 我觉得我的理解比较合理。

@GooMS #34 这听起来像是权限问题

但最简单的方法是，让我学一下 @liuxu 老哥，开个 ssh 让我登上去看看。

后面来的朋友们，这是个吐槽帖啊，不是个技术辩论帖啊，这帖的画风咋歪成这样了 /?

@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 。

读到这的朋友请宽容一下我上面的那些错别字，我自己定制了 rime 的输入方案，还没磨合好.... thanks

@geniussoft #28 bro 你如果想要提出你的不同意见的话，最好完整地加上前音后果，准确地使用术语，这可以提升我们的沟通效率。

or, bro, we can use English to talk about that, if you do not know how to say those concepts in Mandarin clearly.

That's OK for me.

@geniussoft #28 我的假设是 btrfs 已经检测到了 data extent (不是 metadata) 的 checksum 异常，这才表示 data corruption 。

在 raid1 中，这表示 (a) mdadm raid1 主盘 (第一块盘) 中的数据有了问题，但由于 btrfs 只存了一份 data extent 所以 btrfs 修不了。mdadm 再做 scrub 的话，会把主盘上的有了问题的数据覆写到从盘上。此时数据就彻底坏了。

(b) mdadm raid1 的从盘 (第二块硬盘) 中的数据有了问题，但主盘上的数据可能是好的，mdadm 再做 scrub ，会把主盘上的可能 OK 的数据覆写到从盘上。此时数据可能就正常了。

你说的 'raid5/6 默认是不读校验条带的' 是指什么时候不读，不读条带数据，还是不读校验数据？

@geniussoft #26 我没太看懂你这段再说啥，能不能说具体一点？

@gridsah #23

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

这段的 '存储池' 改成 '存储空间'。

@GooMS #22 我没太看懂你在说啥，给一个具体的案例？

@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 你还有其他可以佐证的文档没有。

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

@xianghou #19
@akira #20

我原本的打算就是，客服肯定回答不了，直接转研发，我和他们聊。

@sentinelK #11

我知道，所以，工单到那也就停了。

@geniussoft #12 过了一下 Synology_Data_Protection_White_Paper.pdf

我的理解是，群晖对于 btrfs 做了一些 hack ，让 btrfs 在发现 data extent 的 checksum 不一致时，就从 mdadm 读这个数据的 redundant copy ，然后据此恢复这个 data extent 的数据？

我查了好久群晖如何处理 bit rot 的文档，没想到从这找见了 hhhhh

@devopsdogdog #14 因为群晖的 btrfs 是跑在一层层 device mapper 映射出的设备上的。而 zfs 我见到的，多是直接用硬盘，或者硬盘分区。所以我才去研究群晖对于 btrfs 的用法以及他们的 hack 。

@geniussoft #12 我根据你这段找到了一个 Synology_Data_Protection_White_Paper.pdf 让我先读一读。

@sentinelK #8 emmmmm 你说的好像也没啥毛病，这个角度是回应 toC 业务的情况。我印象里群晖有好多 toB 的业务，所以我试图以一个 toB 业务客户的身份和客户聊，从 toB 的角度看，我问实现细节其实是没啥问题的。

额，应该是我把工作习惯带到这里了吧，我接触的比较多的都是 toB 业务。

至于你提到我说 "我不关心 btrfs 的技术细节" 是因为，我看出客服好像不想回答实现细节，所以我试图变成一个小白用户，让客服直接给我一个结论，能或者不能。

最后客服给了我一个误导性很强的不能.......

@Ericality #6 省流版

群晖的 btrfs 在无硬件故障的情况下，可能出现数据损坏，并且在群晖发现数据损坏之前，不会向用户报告。而且一旦碰到无法修复的情况，要恢复数据就只能靠用户自己的冷备。群晖自带的 mdadm raid 也救不回来。

( 软件和硬件 raid 的核心是高可用，只有 btrfs/zfs 才在 raid 的基础上加了 self-healing 的功能

@GooMS #4 是的，我原先准备今年双十一买个新群晖来替换我 2 盘位的群晖。现在没这个欲望了。

现在我保留群晖的原因只有方便的外网访问，以及 DSM Photos 了。