Btrfs文件系统有一段漫长而又动荡的历史。LWN在2007年就第一次报道过Btrfs。它提供了其他主流Linux文件系统所没有的功能，但可靠性和性能问题阻碍了它的广泛使用。不过，至少有一家公司正在大规模使用Btrfs。Facebook 在2020年北美开源峰会的视频会议上，Btrfs开发者Josef Bacik就介绍了Facebook会在Btrfs上花这么多功夫，以及具体做了哪些，还有什么挑战。

Bacik在一开场就指出，Facebook的每一项服务都在容器内运行，这个技术（也包括其他一些技术）可以使得机器之间（甚至数据中心之间）迁移服务这个工作变得非常容易。Facebook有大量的机器，所以不可能针对每台设备进行逐个的管理维护。该公司希望所有这些机器都尽可能地保持一致，需要可以在任意时间将任意的service转移到任意机器上。该公司有时会刻意让整个数据中心瘫痪掉，以测试其灾难恢复（disaster-recovery）机制是否正常。

Faster testing and more

所有这些容器化服务的root文件系统都使用了Btrfs。不过，Facebook内部最初的Btrfs是用在build server（构建服务器）上。该公司有大量的代码需要，包括网页、移动应用、测试套件以及支持所有这些的底层基础设施。

Facebook的工作流程决定了，没有人会直接将代码提交到仓库。相反，是有一个完整的测试程序会先对每组patch运行一次。build系统会clone公司的代码仓库，打上patch，编译整个系统，然后运行测试。全部完成之后，这些内容就会被清理掉，为下一组patch的测试做准备。实测下来，这个清理阶段其实比较耗时，平均来说需要两三分钟就能删除这些代码目录树。而有些测试中，清理可能需要十几分钟，在这个阶段这台机器无法运行下一个测试。

最终，开发人员发现，要想使用上面这个流程来完成对一组patch的验证，就可能需要花费数小时。所以基础设施（infrastructure）团队决定尝试使用Btrfs。测试系统不需要重新对代码库进行clone操作，而只是做一个snapshot（快照）动作，这个操作一瞬时就可以完成。在测试运行之后，就可以删除snapshot会被删除，从用户空间的角度来看，这个动作也是一瞬时就完成了。当然，后台其实还有一个工作线程（worker thread）在清理快照，但清理快照要比从普通文件系统中删除目录快很多。这个变化就为build系统节省了很多时间，并且减少了三分之一的服务器数量（包括编译和测试所需的机器）。

那次实验效果很好，之后，基础架构团队就全面转向了Btrfs。现在整个构建系统都在使用它。事实证明，改用Btrfs还有一个强有力的理由：它支持磁盘压缩。这里的重点不仅仅是节省存储空间，还包括延长其使用寿命。Facebook在闪存上花了很多钱，不过都是便宜、质量一般的闪存。该公司希望这种存储能够尽可能地延长寿命，这意味着要尽量减少执行的写入周期数（write cycle）。源代码往往具有良好的压缩比，因此压缩就可以大大减少写入的存储block的数量，减缓存储设备的寿命损耗。

Bacik说，这项工作是由基础设施团队完成的，没有借助Facebook的Btrfs开发人员的任何帮助，事实上，他们甚至都不知道有这件事。他对最后取得的效果也甚感惊讶。

然后，就是为开发者提供虚拟机的场景了。Bacik说，Facebook拥有 "数量太多了 "的工程人员；每个开发人员都有一个虚拟机用于他们的工作。这些机器里包含了网站的全部源代码。要想把全部代码都装进分配给每个人的800GB中时（同时还要为一些实际工作留出空间），还是很困难的。这里再一次利用了压缩功能来拯救了大家，而且效果很好，尽管他也承认有一些 "ENOSPC问题"（就是当文件系统耗尽可用空间时产生的问题）。

Facebook代码库的另一个重要部分是这个容器系统本身，内部称为 "tupperware"。这个系统中的容器使用Btrfs作为root文件系统，这就实现了很多有趣的功能。Btrfs具有的发送和接收机制（ ）既可以用来编译base image（基础映像文件），也可以用来实现快速、可靠的升级。当一个任务被部署到某个容器上时，会先对base image（运行着CentOS的某个版本）进行一次snapshot，然后把这个特定的容器运行在这个base image的基础之上。当该service不再需要的时候，清理工作只需删除这个subvolume就可以返回base snapshot了。

此外，Btrfs压缩再一次在降低write I/O这边起到了作用，帮助Facebook充分利用廉价的闪存盘。Btrfs也是唯一一个能与io.latency和io.cost（原io.weight）block I/O controller配合使用的Linux文件系统。他说，这些controller逻辑根本无法与ext4配合工作，而且与XFS配合时也还存在一些问题。他暂时还没空来深入调查这些文件系统上具体的错误。

目前有一个进行中的Project，主要是关于WhatsApp service的。WhatsApp消息通常存储在用户的设备上，但当用户offline的时候，这些消息必须先存储在中心服务器上。考虑到用户的数量巨大，这会耗费相当大的存储空间。Facebook正在使用XFS来支撑这个服务，但遇到了尚未查清的 "weird scalability issues"。Btrfs压缩在这里也能有帮助，并且snapshot对于清理工作总是会很有用。

但是，Btrfs在这个场景中也遇到了扩展性问题（scalability problem）。这些消息都是非常小的压缩文件，小到消息文本通常与文件的metadata（元数据）是存放在一起的，而不是放在单独的数据范围内。这导致文件系统的metadata达到数百GB，并且碎片化程度很高。Bacik说，这些问题已经得到解决，现在"比较顺利"。尽管如此，仍有一些问题有待处理，WhatsApp最终可能不会切换到Btrfs。

The good, the bad, and the unresolved

Bacik最后总结了一下哪些工作得很完美、哪些还有问题。他讲述了一个bug的调试过程，当时Btrfs在与特定的RAID控制器配合工作时不断报告checksum error。凭经验，他认为这种事情是Btrfs的bug，但这次查下来发现RAID控制器在每次重启时都会向磁盘中间写入一些随机数据。这个问题已经发生了好几年，悄无声息地破坏了文件系统。而Btrfs则马上就指出了这里有问题。这时，他开始觉得，也许是时候开始更信任Btrfs了。

另一个意想不到的好处是，Btrfs在追踪微架构处理器（microarchitectural processor）bug方面提供了帮助。与其他文件系统相比，Btrfs往往会给系统的CPU带来更大的压力；像checksum、压缩、以及把许多工作都offload到线程上，这些功能往往会让系统变得非常繁忙。自己制造硬件的Facebook已经遇到了一些被Btrfs暴露出来的CPU问题，这使得它很容易提供复现方法来发送给CPU vendor，从而能让这个问题在今后得到fix。

他说，总的来说，自己花了很多时间来追踪文件系统的系统性问题。作为一个文件系统开发者，他天生就很保守，担心因为自己的过错而导致这个 "世界被毁灭"。而几乎在每一个案例中，这些问题都被证明是来自于硬件，或者系统的其他部分。他说，在质量水平上来看，硬件其实比Btrfs还差。

不过，他最高兴的是，公司里的大部分Btrfs应用场景都是由其他team自发开发出来的。他从来没有去告诉其他团队需要使用Btrfs，但他们还是因为Btrfs的优点而选择了它。然而，并不是一切完美的。在他的清单中，排在首位的是Btrfs耗尽空间时表现出来的bug，这个问题从一开始就一直困扰着Btrfs。

"It's not Btrfs if there isn't an ENOSPC issue", he said.

他的职业生涯的大部分时间都在追查这些问题。虽然还有一些问题需要修复，但目前这些问题已经很少发生了。目前，他终于自认为对ENOSPC的处理状况比较满意了。

目前出现的可扩展性问题，主要是上面描述的WhatsApp这种场景。他说，这些bug凸显了一些有趣的corner case，但并不是真的很难解决的。还有一些 "weird, one-off issues（奇怪的、一次性的问题）"，这些问题主要影响了block subsystem的维护者Jens Axboe，"我们喜欢Jens，所以我们专心解决了这些问题"。

在仍然需要解决的问题中，排在首位的是quota group。他说，quote group的开销太高了，而且有时候系统就是会出错。他计划在明年要解决这些问题。有用户希望看到subvolume level的加密功能，这将可以安全地把具有不同隐私要求的服务给叠加起来。Omar Sandoval现在正在研究这个功能。

然后是RAID支持的问题，这是Btrfs另一个长期存在的问题领域。他说，基本的striping和mirroring功能可以很正常地工作，而且多年来一直如此。但RAID 5和6有 "lots of edge cases"，而且一直是出名的不可靠。这些问题也在他的清单上，但解决这些问题需要在未来一两年内做 "大量的工作"。

（End）