LWN：内核何时能合入bcachefs？

点击上方蓝色字关注我们~

Bcachefs gets closer

By Jonathan Corbet
July 11, 2019

每当要给Linux增加新的文件系统支持的时候，耐心都是非常重要的。Btrfs花了多年才成熟，甚至有些人认为它仍然尚未完善。期待Tux3的用户，已经从2008年等到现在了，2018年的时候开发者仍然说在持续开发完善中。跟这些比起来，bcachefs还是很年轻的，大概4年前问世。这个下一代文件系统的开发一直持续进行中，bcachefs的开发者Kent Overstreet最近宣布他非常渴望“赶紧合进去”，不过目前仍然有一些阻碍。

bcachefs起源于bcache(Bcache是Linux内核块设备层cache，支持多块HDD使用同一块SSD作为缓存盘)，不过后来变成一个独立的项目了。它也同其他那些新的文件系统类似，都使用了copy-on-write方式工作，也就是说数据写入的时候不会直接覆盖原有数据，而是写入一个新的未知。这样就能实现多种有意思的功能了，例如data checksumming（数据校验）, compression（压缩）, multiple-device（多设备支持），RAID，hierarchical storage management（多级存储管理），snapshot（快照），当然还有非常好的性能表现。bcachefs的进展比较缓慢，主要还是因为开发者获取的支持较少。Overstreet已经在Patreon发起众筹（译者注：强烈推荐看一下这个众筹，比较了多个Linux主流文件系统的优缺点：https://www.patreon.com/bcachefs  ），希望借此能推动项目快速前进。看起来众筹还是有些效果的，这个文件系统已经接近准备完成的状态了：“多年工作现在终于来到了一个值得纪念的日子了，非常期待能最终对外界发布的那一刻。”

希望尝试新文件系统的用户，估计很快会发现这个项目比较缺乏的还是文档。所以通常来说用户需要下载源代码，然后尝试着搭建起这个文件系统。不过至少bcachefs还是有个man page介绍了基本用法，开了个好头。

Overstreet认为bcachefs代码的状态已经达到合入mainline的标准了。不过用户还得再多等一会儿，目前还有一些阻碍，首先是Linus Torvalds对这个代码库管理方面提出了一些抱怨，清理这些东西需要花时间。

Core-kernel changes

除此以外，还有一些kernel核心代码需要改动才能支持bcachefs。Overstreet也很明白这里会引出不少反对意见。毕竟文件系统的特定实现方案里的代码改动不会影响其他那些不使用这个文件系统的用户，不过修改kernel核心部分的代码会产生广泛的影响了。所以目前虽然bcachefs代码本身还没有发到mailing list上，但是其他部分需要做的改动已经先发布上来进行review了。

其中一个改动是增加了一个新的lock实现，名为SIX lock。这种锁是reader/writer lock，不过勇气来很特别。通常的reader/writer lock允许很多reader来同时访问这个受保护的区域，而writer则必须是独占访问。SIX lock则不通，它把writer这边改成了两个步骤，所以需要写这些受保护的数据结构的代码需要先获取一个“intent" lock。这个"intent" lock只能有一个拥有者，这样第二个线程来抢"intent" lock的时候就会被阻塞住，等待第一个线程释放lock。但是拿到intent lock之后并不会阻塞reader的访问，reader线程仍然可以访问这个受保护的数据。

在需要真正写内容的时候，就要把intent lock升级为一个write lock，这样确保任何其他人（包括reader）也就无法再访问这个区域了。这个方案的好处是在intent lock阶段，writer就能访问这部分数据（只是不能写入而已），这样writer就能减少它独占数据并且其他reader无法访问的时间长度，从而改善并发行。

Overstreet认为SIX lock"看起来并没有太多争议"。不过Torvalds确实建议最好能把这个“intent”阶段加到kernel的rwsem lock架构里去，而不是引入一个全新的lock机制。Dave Chinner反对这个观点，他觉得rwsem已经太脆弱了，不要再增加它的复杂性了。目前最终怎么做还没有达成一致，不过看起来SIX locks到时候应该还是能够得到合入的。

此外，还有一个新增的锁机制，称为pagecache_lock。针对每个地址空间都有一个pagecache_lock，目的是管制在page cache里新加page的动作。这个锁可以有两种获取模式，分别是add和block。前者是用于新增page的时候，而后者是用来阻止其他人新增page。多个线程可以同时获取同一个锁，只要他们都用同一个工作模式。这样多个线程就能同时增加page到page cache了。而如果修改了所得模式，就需要引入一些等待了。Torvalds不喜欢这个锁机制，认为“我们不需要这种hacky recursive things”。

Overstreet也赞同这个lock机制不是很完美，他说“这个实现故意做的特别难看，就是因为期待有人能提出一个更优雅的解决方案”。这招在Linux社区里通常确实很有效。不过他认为这个lock机制的存在是非常必要的。目前kernel里面，很多操作（例如direct I/O）都会把page从page cache里摘除掉，否则这些绕过page cache的访问就可能导致数据出错。不过没有任何机制能阻止系统在page fault的时候再把这些page加回page cache，无论是user-space代码，还是kernel的自动提前预取功能等等机制都可能导致这个行为。如果page在错误的时间重新加入cache，那么就会导致数据错误。

这个问题大家都赞同是确实存在的，不过关于解决方案，有很多不同观点。Torvalds建议应该加入某种page-level locking机制。Chinner则在准备一个range lock机制有可能能解决问题，他还认为会有越来越多的I/O操作都期望彻底绕过page cache。Matthew Wilcox提了另一个方案，就是禁止buffered I/O操作在有direct I/O进行的时候add page到page cache，不过有时候direct I/O的行为其实也跟buffered I/O一样，尤其是相关的page早已经在cache中存在的时候。

目前这个问题目前在mailing list里面尚未讨论出个结论。有多种建议提出，而Overstreet需要证明给大家看他自己的方案是最棒的。

最后，在bcache代码中还有一个“closure”机制。这里的closure本质上是一个reference count，以及相应的用于在等待某些事件发生的一些API。Overstreet希望把closure代码移到lib目录下去，这样就能有更多地方利用这个机制。虽然大多数reviewer觉得无所谓，Christoph Hellwig则强烈反对这个建议。不过他目前还没有仔细讲解为什么反对。

因此，看起来还是有几个问题需要解决的，甚至bcachefs的代码本身还没有开始让大家review，这部分后续肯定也是需要仔细审查的。文件系统开发者根据历史经验，非常确信如果在文件系统代码尚未成熟之前合入，会引出很多长远问题。所以尽管bcachefs看起来非常有用、进展也很快，但是看起来大概率还是无法很快合入mainline kernel。

全文完

LWN文章遵循CC BY-SA 4.0许可协议。

极度欢迎将文章分享到朋友圈 
热烈欢迎转载以及基于现有协议上的修改再创作～

长按下面二维码关注：Linux News搬运工，希望每周的深度文章以及开源社区的各种新近言论，能够让大家满意～