Btrfs to the mainline?

One of the kernel projects that seems to be attracting a fair amount of attention these days is the new, copy-on-write filesystem, Btrfs. While still rather immature—the disk format is slated to be finalized by the end of the year—Btrfs has reached a point where lead developer Chris Mason wants to start talking about when to merge it into the mainline. Some are advocating moving quickly, while others are a bit more skeptical that merging it will lead to faster development.

Merging Btrfs would have a number of advantages, but more eyes is what Mason is seeking:

Typically, kernel code is not merged until it is ready, but an argument can be made that filesystems, like device drivers, are sufficiently isolated from the rest of the kernel that an early inclusion will do little harm. Also, a kind of precedent was set by the early "merge" of ext4, though that was an evolution of the existing ext3 filesystem, while Btrfs is entirely new. Andrew Morton has been encouraging Mason to get Btrfs "into linux-next asap and merge it into 2.6.29". He describes his reasoning:

Adrian Bunk is not convinced that an early merge will bring the benefits that Morton is touting. He points to an early ext4 development plan, noting that the timelines outlined in that message were, perhaps, overly optimistic. "When comparing with what happened in reality it kinda disproves your 'acceleration' point".

There is a difference, though, between ext4 and Btrfs, that Serge Hallyn points out:

The original timeline showed mid-2007 as a target for a stable ext4 filesystem, but the project overshot that by a year or so. A recent patch proposes renaming ext4dev to ext4 because it "is getting stable enough that it's time to drop the 'dev' prefix". Unexpected difficulties led to ext4 development taking longer, as Mason describes:

Many seem to think that Btrfs is different, but it still has a ways to go. Currently, it does not handle I/O errors very well, while running out of space on the disk can be fatal. But it is getting close to usable—at least for testing and benchmarking. Getting the code into the mainline would cause more folks to look at it, as well as test various filesystem changes against it. Mason gives an example of how that can work:

Btrfs has an aggressive schedule that targets a 1.0 release this year. The focus of that release is to nail down the on-disk format so that changes after that point will be backward compatible. Given that 2.6.29 will likely be released in early to mid-2009, it seems quite possible that Btrfs will be "merge-worthy" by then, which means that it really is not premature to start considering it now.