腾讯云在这次事件中的结论表述为因受所在物理硬盘固件版本Bug导致的静默错误,文件系统元数据损坏:
根据这个表述,故障应出现在硬盘固件故障导致的文件系统元数据损坏。这其中,涉及具备因果关系的三个知识点:
硬盘固件故障—>文件系统元数据损坏—>文件损坏。
在此大致画一下腾讯云可能用到的存储架构方案。
数据恢复工程师视角看腾讯云静默损坏事件
带*号的是不一定存在的存储链。事实上,这个逻辑肯定不准确,比如有些环节精减或不需要,有些环节有更详细的设计等。但是不是和真实场景一致不重要,重要的是,问题如果出现,总会出现在我列出的项或我没列出的项中(废话),这些项是相互关联的。
我们再重复一下现象:硬盘固件故障(层1故障)导致的文件系统元数据损坏,从而导致部分文件校验出错,导致文件损坏。针对现象,努力从上述10个环节匹配,每一层会有可能出错,导致上述故障吗:

 第1层:存储介质

以硬盘为例,每个构成数据的最小单位扇区都会有严格的校验,包括扇区头部的CRC校验以及地址标识校验。理论上,如果层1的数据出现磁力失真(或闪存状态丢失)等比特出错,其头部校验不匹配时,介质控制器就会向上层反馈错误(一般表现为坏扇区),上层会启动修正模式进行修正。
当然也有例外,比如硬盘内部程序出错,根本不按上述原则执行,忽略校验值的情况下,任何对数据的篡改都是可以的。可以表现为腾讯所说的静默损坏(即层1在合理的逻辑里偷梁换柱)。这种情况,基本大帽子就能扣在硬盘固件BUG这上面了,但硬盘固件这种BUG是致命的,等同于我们存进银行的钱不知什么原因变多或变少,没有硬盘厂商站出来承认,也没有紧急发布BUG修复固件,完全归因于硬盘固件,可能偏激了些(也可能事件背后有固件BUG的原因,那也应该是添油加醋型的)。

 第2层:RAID

RAID自身有冗余算法,可实现在部分介质(硬盘)损坏后,由其他成员及算法控制来接管损坏硬盘的数据服务,保证上层业务不中断,不出故障。但RAID也并非完全可靠。
一种错误是软RAID中的写漏洞(write hole),如果是软RAID,这无法避免,可能导致腾讯本次事故。但软RAID是玩具产品,自然腾讯是不会用这种方案的。
还有可能的错误是buffer dirty,当缓冲数据掉电清空,或有意无意损坏后,会导致数据出现本例的表现错误。但这个原因可以很容易推到控制器BUG上面,腾讯没提及这个原因,或者是他们没找到病根