@mhycy 75
目前从实际应用来看架构上除了存储集群太小（具体多大算大 /小 /合适，这个数据我也没接触过，不清楚）之外，对应的疑问 2，其他的没看到什么硬伤，毕竟运行了这么多年，更多的是流程、规范和细节上（比如计算资源配比、存储容量告警阈值等）可优化的点。

因为磁盘可以正常读取，不会报错，只是读出来的数据不对，也不会触发硬件的异常告警。

@mhycy #68
这个我也不清楚了。

#67
可能之前没有正确理解的意思，疑问 3 是否是迁移过程中仓库 I 的读取到这个磁盘的请求也一直没有报出 I/O 错误？
我的理解可能是这样的，首先是只是部分数据读出来的不一致，并不是所有数据，且这部分数据大部分数据是冷数据，存在读取很少或根本没有读取到情况；仓库 I 一直正常的完整读取，即使是读取到这个副本的错误数据，校验失败，但是直接读取其他两个正常的副本进行了校验，在业务方看来读取是正常的，错误数据占比非常小，根本达不到报警的阈值， 只是排队去做异步修复了。
只是个人推测。

@mhycy #59
我并不是 CBS 存储的产品和研发部门的，是其他部门的，细节要看后续有没有架构分享之类的内容了。
回这篇帖子主要是也了解过分布式存储的一些东西，虽然没有做过，并且这个帖子是在讨论技术，而不是在互怼。

@mhycy #58 我找人问了下，确认是 SSD

理论、协议和工程实现有时候差距还是不小的，尤其涉及到具体管理的时候，也不能说一定就是坑吧，当然具体实现我也不了解。

@mhycy 嗯对，就是写入的时候是没有回读校验的，毕竟我也只是半把刀，有些名词不提就想不起来。

缓存是有的，但是迁移没有通过缓存。

具体的迁移流程细节就完全不清除了，理论上应该是这个流程，镜像加快照流水。

@firefox12 只有仓库 I 和仓库 II， 仓库 II 中的 3 副本数据因为读取就是没校验的错误数据，写入的全错；仓库 I 中 3 副本 1 份错误的，2 份正确的，正常的操作都不会有问题，也可以自动修复。但是把客户的操作切到仓库 II 之后，仓库 I 的数据回收就会把 3 个副本全部删除掉了，然后其他客户的写入又会把这 3 个副本原本的数据空间覆盖掉。

@mhycy #43
我#45 #47 的回答想了下确实是有问题的，因为我也不了解细节，我了解到的信息也只是公开的故障复盘报告。所以应该还是去随机访问的，但是正好访问到了出问题的这个副本的这个磁盘，导致读取到了错误的数据，并且没有进行校验。

@mhycy 当然一个副本也是随机散列到不同磁盘上的，所以这里其实并不是数据完全丢失，其实是丢失了一部分数据，主要是部分系统元数据从这块磁盘上读的错误，影响了更多的实际数据。

@mhycy 实际的用户访问业务系统确实是你说的，随机（ hash 或者 range 或者 hash+range ）打散的，但是数据迁移据我了解没去做随机打散访问请求，就是指定的其中一个副本去访问的，这里的流程是有问题的。

@firefox12 我的意思是写入的时候不校验计算出来的块校验信息，3 副本之间的校验信息对比肯定要做的。

@firefox12 写入会计算校验信息并写入，但是不进行校验是我了解的原理，工程实现怎么做的细节不清除。

老副本的问题还是去看下公告的第二个违规操作吧，数据立马会收掉了，仓库 1 还一直有非常多的客户再写入的。也就是楼主的疑问 2.

@mhycy 静默错误是有可能导致磁盘本身的块校验时效。存储系统的块校验和三副本校验公告是迁移过程中把校验关了，根本没校验，这个就是严重的问题。。。

@firefox12 建议你先看下公告的具体内容吧。

@mhycy 存储了解的意思是了解部分分布式存储的原理，但不了解出问题的 CBS 的架构。

@mhycy 我并不是做存储的，主要是做网络的，存储了解，但没做过，具体架构细节我也不清除。

@johnjiang85 腾讯云的对象存储叫 COS，默认高频是 3 副本，低频是 EC 纠删码存 1.33 份，可以自己选。

@firefox12 出问题的是 CBS，块存储，且是系统盘。