摘要：昨天（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开发每周谈
作者：麦子迈
它能自动分析文件热度，自动增加文件的副本么？
它能很简单的解决节点的网络或者硬盘i/o的负载均衡问题么？
找个靠谱的分布式数据库存储文件的原信息，然后用一堆nginx节点做无状态的文件服务器集群，写个自动管理这些数据库和文件服务器的代码，一切就搞定了，这么简单的事，至于搞这么复杂？
引用来自“中国首席鉴黄师”的评论
对于只会背新闻的人我并不指望他能看懂这篇文章的意思，毕竟作者已经很明白的说清楚了『所以，这些都是为了说明每一个 Bug 正常的途径应该是首先发到社区的 Bug Tracker，然后通过邮件列表，IRC 进行讨论，而不是娱乐圈的爆大料玩法』
对于没有看懂的小伙伴，我来解释一下，对于开源软件，它并不是一个人的工作成果，所以发现了 bug，应该第一时间去社区去反馈 bug。
你要曝光不是不可以，除非你的曝光最后被证明是名副其实的，不然就是哗众取宠的小丑。
为什么这么说，因为这个 bug 根据上文作者的描述，并没有曝光的标题描述的那么夸张，那么你弄一个大标题，无非就是想搞一个大新闻，为公司牟利，但是你却诋毁了一个开源软件，使他给人一种代码不稳健开发人员技术不行的感觉，而这个软件是一群热心的开发者共同维护的开源软件，最终损害的是大家的开发热情，换句话说就是是给你开发了东西你一分不给还要踩它一脚搞个大新闻的意思
连别人说的什么都没看懂的人，那么多新闻也真是白背了
引用来自“风筝上的少年”的评论
可是这个bug很容易复现啊，是客观存在的啊。。你要么就直接关闭这个特性，不让使用。为什么总是记者否认呢？
引用来自“wkgcass”的评论
谁没事干写1300多个片啊？引用来自“wkgcass”的评论
不对，刚说错了，是谁没事干开个总大小>10M呀。。。引用来自“风筝上的少年”的评论
我不懂，10 M 很大吗？引用来自“wkgcass”的评论
这。。。拜托有点常识啊。。。但是报告也要按照基本法，为了赚眼球就夸大bug的影响也是不可取的。任何稍大的开源项目都有bug反馈平台，将发现的问题反馈给开发者，提供足够的信息以供开发者验证、确定bug的级别，这才是正确的体位。。。
引用来自“中国首席鉴黄师”的评论
对于只会背新闻的人我并不指望他能看懂这篇文章的意思，毕竟作者已经很明白的说清楚了『所以，这些都是为了说明每一个 Bug 正常的途径应该是首先发到社区的 Bug Tracker，然后通过邮件列表，IRC 进行讨论，而不是娱乐圈的爆大料玩法』
对于没有看懂的小伙伴，我来解释一下，对于开源软件，它并不是一个人的工作成果，所以发现了 bug，应该第一时间去社区去反馈 bug。
你要曝光不是不可以，除非你的曝光最后被证明是名副其实的，不然就是哗众取宠的小丑。
为什么这么说，因为这个 bug 根据上文作者的描述，并没有曝光的标题描述的那么夸张，那么你弄一个大标题，无非就是想搞一个大新闻，为公司牟利，但是你却诋毁了一个开源软件，使他给人一种代码不稳健开发人员技术不行的感觉，而这个软件是一群热心的开发者共同维护的开源软件，最终损害的是大家的开发热情，换句话说就是是给你开发了东西你一分不给还要踩它一脚搞个大新闻的意思
连别人说的什么都没看懂的人，那么多新闻也真是白背了
引用来自“风筝上的少年”的评论
可是这个bug很容易复现啊，是客观存在的啊。。你要么就直接关闭这个特性，不让使用。为什么总是记者否认呢？
引用来自“wkgcass”的评论
谁没事干写1300多个片啊？引用来自“wkgcass”的评论
不对，刚说错了，是谁没事干开个总大小>10M呀。。。引用来自“风筝上的少年”的评论
我不懂，10 M 很大吗？引用来自“xyz20003”的评论
开源作者认为你用之前要看配置文档，已经注明有问题的配置就不要开。用户认为你知道有问题的配置还放出来？当然，这个用户跟谁也没沟通，直接说我发现了一个天大
的bug，也算是汗颜。
引用来自“中国首席鉴黄师”的评论
对于只会背新闻的人我并不指望他能看懂这篇文章的意思，毕竟作者已经很明白的说清楚了『所以，这些都是为了说明每一个 Bug 正常的途径应该是首先发到社区的 Bug Tracker，然后通过邮件列表，IRC 进行讨论，而不是娱乐圈的爆大料玩法』
对于没有看懂的小伙伴，我来解释一下，对于开源软件，它并不是一个人的工作成果，所以发现了 bug，应该第一时间去社区去反馈 bug。
你要曝光不是不可以，除非你的曝光最后被证明是名副其实的，不然就是哗众取宠的小丑。
为什么这么说，因为这个 bug 根据上文作者的描述，并没有曝光的标题描述的那么夸张，那么你弄一个大标题，无非就是想搞一个大新闻，为公司牟利，但是你却诋毁了一个开源软件，使他给人一种代码不稳健开发人员技术不行的感觉，而这个软件是一群热心的开发者共同维护的开源软件，最终损害的是大家的开发热情，换句话说就是是给你开发了东西你一分不给还要踩它一脚搞个大新闻的意思
连别人说的什么都没看懂的人，那么多新闻也真是白背了
引用来自“风筝上的少年”的评论
可是这个bug很容易复现啊，是客观存在的啊。。你要么就直接关闭这个特性，不让使用。为什么总是记者否认呢？
引用来自“wkgcass”的评论
谁没事干写1300多个片啊？引用来自“wkgcass”的评论
不对，刚说错了，是谁没事干开个总大小>10M呀。。。引用来自“中国首席鉴黄师”的评论
对于只会背新闻的人我并不指望他能看懂这篇文章的意思，毕竟作者已经很明白的说清楚了『所以，这些都是为了说明每一个 Bug 正常的途径应该是首先发到社区的 Bug Tracker，然后通过邮件列表，IRC 进行讨论，而不是娱乐圈的爆大料玩法』
对于没有看懂的小伙伴，我来解释一下，对于开源软件，它并不是一个人的工作成果，所以发现了 bug，应该第一时间去社区去反馈 bug。
你要曝光不是不可以，除非你的曝光最后被证明是名副其实的，不然就是哗众取宠的小丑。
为什么这么说，因为这个 bug 根据上文作者的描述，并没有曝光的标题描述的那么夸张，那么你弄一个大标题，无非就是想搞一个大新闻，为公司牟利，但是你却诋毁了一个开源软件，使他给人一种代码不稳健开发人员技术不行的感觉，而这个软件是一群热心的开发者共同维护的开源软件，最终损害的是大家的开发热情，换句话说就是是给你开发了东西你一分不给还要踩它一脚搞个大新闻的意思
连别人说的什么都没看懂的人，那么多新闻也真是白背了
引用来自“风筝上的少年”的评论
可是这个bug很容易复现啊，是客观存在的啊。。你要么就直接关闭这个特性，不让使用。为什么总是记者否认呢？
引用来自“wkgcass”的评论
谁没事干写1300多个片啊？引用来自“中国首席鉴黄师”的评论
对于只会背新闻的人我并不指望他能看懂这篇文章的意思，毕竟作者已经很明白的说清楚了『所以，这些都是为了说明每一个 Bug 正常的途径应该是首先发到社区的 Bug Tracker，然后通过邮件列表，IRC 进行讨论，而不是娱乐圈的爆大料玩法』
对于没有看懂的小伙伴，我来解释一下，对于开源软件，它并不是一个人的工作成果，所以发现了 bug，应该第一时间去社区去反馈 bug。
你要曝光不是不可以，除非你的曝光最后被证明是名副其实的，不然就是哗众取宠的小丑。
为什么这么说，因为这个 bug 根据上文作者的描述，并没有曝光的标题描述的那么夸张，那么你弄一个大标题，无非就是想搞一个大新闻，为公司牟利，但是你却诋毁了一个开源软件，使他给人一种代码不稳健开发人员技术不行的感觉，而这个软件是一群热心的开发者共同维护的开源软件，最终损害的是大家的开发热情，换句话说就是是给你开发了东西你一分不给还要踩它一脚搞个大新闻的意思
连别人说的什么都没看懂的人，那么多新闻也真是白背了
引用来自“风筝上的少年”的评论
可是这个bug很容易复现啊，是客观存在的啊。。你要么就直接关闭这个特性，不让使用。为什么总是记者否认呢？
用户认为你知道有问题的配置还放出来？当然，这个用户跟谁也没沟通，直接说我发现了一个天大
的bug，也算是汗颜。
引用来自“中国首席鉴黄师”的评论
对于只会背新闻的人我并不指望他能看懂这篇文章的意思，毕竟作者已经很明白的说清楚了『所以，这些都是为了说明每一个 Bug 正常的途径应该是首先发到社区的 Bug Tracker，然后通过邮件列表，IRC 进行讨论，而不是娱乐圈的爆大料玩法』
对于没有看懂的小伙伴，我来解释一下，对于开源软件，它并不是一个人的工作成果，所以发现了 bug，应该第一时间去社区去反馈 bug。
你要曝光不是不可以，除非你的曝光最后被证明是名副其实的，不然就是哗众取宠的小丑。
为什么这么说，因为这个 bug 根据上文作者的描述，并没有曝光的标题描述的那么夸张，那么你弄一个大标题，无非就是想搞一个大新闻，为公司牟利，但是你却诋毁了一个开源软件，使他给人一种代码不稳健开发人员技术不行的感觉，而这个软件是一群热心的开发者共同维护的开源软件，最终损害的是大家的开发热情，换句话说就是是给你开发了东西你一分不给还要踩它一脚搞个大新闻的意思
连别人说的什么都没看懂的人，那么多新闻也真是白背了
引用来自“风筝上的少年”的评论
可是这个bug很容易复现啊，是客观存在的啊。。你要么就直接关闭这个特性，不让使用。为什么总是记者否认呢？
引用来自“中国首席鉴黄师”的评论
对于只会背新闻的人我并不指望他能看懂这篇文章的意思，毕竟作者已经很明白的说清楚了『所以，这些都是为了说明每一个 Bug 正常的途径应该是首先发到社区的 Bug Tracker，然后通过邮件列表，IRC 进行讨论，而不是娱乐圈的爆大料玩法』
对于没有看懂的小伙伴，我来解释一下，对于开源软件，它并不是一个人的工作成果，所以发现了 bug，应该第一时间去社区去反馈 bug。
你要曝光不是不可以，除非你的曝光最后被证明是名副其实的，不然就是哗众取宠的小丑。
为什么这么说，因为这个 bug 根据上文作者的描述，并没有曝光的标题描述的那么夸张，那么你弄一个大标题，无非就是想搞一个大新闻，为公司牟利，但是你却诋毁了一个开源软件，使他给人一种代码不稳健开发人员技术不行的感觉，而这个软件是一群热心的开发者共同维护的开源软件，最终损害的是大家的开发热情，换句话说就是是给你开发了东西你一分不给还要踩它一脚搞个大新闻的意思
连别人说的什么都没看懂的人，那么多新闻也真是白背了
为什么总是记者否认呢？
如果是软件的“默认配置”下出现的问题，使用这种方式进行“爆料”，个人认为虽然有些不妥，但是为了扩大影响力，这种方式还是有点道理的，从消费者的角度来看。类似于openssl，android这些的重大bug……
但是ceph的这个bug是怎么回事，首先你得打开配置，进行这些配置不应该了解这些配置的意义么。