摘要：昨天（10月12日）开源中国发布了一篇“有云存储团队公布Ceph中最严重数据不一致BUG!”，引起业界的广泛关注和热烈讨论。ceph开发者就这个问题进行了回复，请看…… 其实我是在 10.12 号晚上看到这个这个帖子，但是当时被删除了。因为微信保留了截图，所以我看到是关于那个 Fiemap 的 Bug。当时我还很高兴终于找到这个问题了，因为在大概 1 周前在 ceph-devel 邮件列表里开发者质疑 XFS Fiemap 有严重 Bug。然后，笔者和 XFS 的主要开发者 Jeff Liu 都回应了这个 Thread，并非常希望能够找到问题，虽然看起来并不是一个容易碰到的 Bug。因为据我所知使用 Fiemap 的集群非常多。在 10.12 号晚上看到部分内容后，半夜回去我还特地回复了 ceph-devel 邮件列表表示祝贺，又是一次非常棒的社区协助然后发现问题，虽然这个问题如我在邮件所说，影响非常小。 但是在 10.13 号的这个 "Ceph 中最严重数据不一致 BUG" 标题还是震惊了我，但是下午看到时笔者还是默默的忍住了，毕竟大家在社区还是经常一起协作的，不希望公司的市场行为影响到工程师之间的合作。但是看到后来朋友转发了开源中国的新闻以及后面的评论(https://www.oschina.net/news/78022/ceph-inconsistency-of-data-bug)，笔者认为作为 Ceph 社区的开发者，还是有义务去澄清的，这无关公司，而是以社区的名义。而且这不仅仅是 Ceph 社区，更有无辜躺枪的 XFS。 让笔者来重头梳理一下这个 Bug: Ceph 的 FileStore 使用了文件系统作为对象的管理和组织平面，XFS 从 D 版本开始就是社区推荐的版本，直到 Jewel 版本社区彻底宣布只支持 XFS，当时的邮件列表还掀起了 EXT4 保卫战。当然，最后 Ceph 还是放弃了其他文件系统。而我们知道，RBD 是 Ceph 的块存储场景，也是最主要的 Ceph 使用面，RBD 的 IO 主要特点是稀疏读写，因此通常来说一个对象在文件系统上数据是稀疏存在的。比如一个 4M 对象，很可能只有几百 KB 的实际数据，文件系统提供的稀疏存储能力大大增加了存储有效空间。但是，在 Ceph 的 Recovery 时候进行对象传输时，默认实现时直接读取整个对象文件，然后进行传输，很可能导致一个稀疏对象最后恢复成一个全是零的 4M 对象，大大增加了恢复带宽和存储空间利用。因此，Ceph 使用了文件系统的 Fiemap 接口来实现稀疏读写。但是由于 Fiemap 这个接口在老版本 Kernel 中充满 Bug，所以社区的主流声音时反对开启 Fiemap，并且默认也是关闭 Fiemap。除非用户非常确信自己有能力解决问题。 所以，这个 Bug 的第一个前提是开启 Ceph 社区认为用户自己需要承担测试责任的 Fiemap，这个选项叫做 "filestore_fiemap"。大家可以看 Ceph 每个版本，没有任何一个版本是默认开启的。但是，这个 Bug 的前提条件还没结束，第二个条件是对象必须具有 1364 个数据片，因为在 XFS 实现里，每次 Fiemap 调用都最大返回 1364 个数据片，所以当一个对象超过 1364 个空洞时，会造成 FileStore 获取 Fiemap 少于实际数据量。当然，XFS 的 Fiemap 实现是没问题的，只是确实很少有普通开发者知道这个 Hacky，因此，Ceph 的 FileStore 也错误的使用了这个 API，造成了最大单对象 1364 个数据片的问题。但是，在理论上，要具有 1364 个数据片至少要 10912KB 的文件。这是理论值。而 Ceph 的默认 RBD 对象大小是 4MB，在众多的 Ceph 邮件列表中都提到了，4MB 是推荐的对象大小。 因此，这个 Bug 很清晰了，在 Ceph 的两个非默认选项都修改后，在极端情况下会发生这个问题。所以，后来跟社区的讨论中，我们没觉得是否要在社区修复这个 Bug，因为从始至终，社区都没推荐这个使用方法，而是用户承担风险。 在 敞开来讲，Ceph 每年发布一个长期维护版本，每半年发布一个开发稳定版本，Ceph 每个长期维护版本有接近 5 个开发者维护，包括 Redhat，Suse，Mirantis 的众多工程师参与。每天我们都可以看到大量的 Bug Fix Backport 回稳定版本，Hammer 版本至今已超过 300 个 Bug Fix。所以，社区认为并不需要紧急 Backport 的一个 Bug 竟然被认为是 “ Ceph 中最严重数据不一致 BUG”。笔者认为这个太伤害社区的开发者对于一个开源项目的热情了。 再举一个例子，在前两个月，Ceph 实际上确实发现了一个有可能数据不一致的 Bug，是跟 RBDCache 有关。笔者很早就参与到了这个 Bug 的讨论，跟 Greg 和 Jason 都聊过，坦率来讲，这个 Bug 非常严重需要尽早让用户了解。但是任何一个 Bug 的确认到复现，修复都是一个过程，不负责任的提前“爆料”对用户和社区都是一个伤害。在大约 2 周后，社区宣布修复该 Bug，并 backport 到 Jewel。但最后实际上并没有像刚开始一样预料严重，踩到 Bug 的概率非常低，且跟上层应用非常相关，Windows 情况下更容易发生，跟 Windows 对于 IO 的管理有关。Linux 情况下在 PageCache 的行为下基本无法发生。实际上，我们内部也早已经找到 Windows 下的必现用例，但是仍然坚持到社区宣布 Bug Fix，鉴定工作完成后才对外透露。毕竟，先关掉 Cache 可以快速避免。 所 以，这些都是为了说明每一个 Bug 正常的途径应该是首先发到社区的 Bug Tracker，然后通过邮件列表，IRC 进行讨论，而不是娱乐圈的爆大料玩法。这对于任何社区开发者和不知情的用户都是巨大的伤害。任何你认为的大 Bug，实际上最后可能影响很小，也可能以为是小问题，最后影响很大。Ceph 社区拥有大量的 PB 级别用户，加上 Ceph 数百台机器的自动化测试集群，实际上每一个稳定版本在过去几年证明都是经得起考验的。 贡献开源社区是非常好的，但是消费“开源”是非常伤害社区的。希望真正热爱开源的公司珍惜开源项目，而不是无限夸大毁它，说实话，这种方式已经超过社区开发者的容忍。 以下是 Ceph 跟 Fiemap 斗争史: 1. http://tracker.ceph.com/issues/1222: 2011年的时候，Ceph 就发现 Fiemap 问题 2. http://tracker.ceph.com/issues/2328: 2012 年的时候，因为老版本 Kernel 文件系统的 Fiemap，Ceph 正式关闭 Fiemap 选项，并且警告用户开启 3. http://tracker.ceph.com/issues/10463: 2015 年，Intel 工程师用 seek_data/seek_hole 来取代 fiemap，但是由于以前的阴影，仍然没有默认打开 seek_data/seek_hole 所以，可以看到 Ceph 主要是由于在11年的时候启用了 Fiemap，而留下了 fiemap 的历史问题，通过选项方式关闭。 最后附上相关链接: 1. XFS Fiemap 使用讨论 (http://www.spinics.net/lists/xfs/msg38001.html) 2. Ceph Devel 讨论(http://www.spinics.net/lists/ceph-devel/msg32915.html) 3. 讨论 Ext4 (http://lists.ceph.com/pipermail/ceph-users-ceph.com/2016-April/008886.html) 稿源：Ceph开发每周谈 作者：麦子迈 |
