Btrfs is, by many accounts, the next-generation filesystem for Linux
systems. It has, in fact, been the next-generation filesystem for a few
years now; progress in the filesystem area often seems to be slow. But
btrfs has been maturing to the point that it is highly usable in a
number of environments. The list of btrfs users may grow significantly
toward the end of this year if a proposal to make it the default filesystem
for the Fedora 16 release is adopted.
That proposal was made by btrfs developer
Josef Bacik. Josef would not only like to see btrfs as the default F16
filesystem; he would like to stop using the LVM volume manager in favor of
the internal volume management built into btrfs. As he notes: "Fedora
16 is a very aggressive target, which is also why I'm bringing it up now.
I think we will be ready by then." There are a few things that will
have to happen, though, for that to be true.
For example, there is the little problem that there is still no filesystem
checker for btrfs. That is, according to btrfs
creator Chris Mason, the biggest missing feature in the filesystem at
the moment. He also said that he is working on it full time, so this
particular gap should be filled sometime in the near future. That said,
filesystem checkers, like the filesystems themselves, require a certain
amount of time to mature into the kind of rock-solid behavior that users
tend to expect. The btrfsck program will certainly have to evolve over
time as the various ways in which filesystems can become corrupted are
Josef noted that support in the GRUB bootloader is another open problem.
Patches adding support to GRUB1 exist, but they would have to be carried by
Fedora, since there is no functioning upstream for GRUB1. The alternative
is to move the distribution to
GRUB2, a tool which has the added advantage of an existing upstream
development community. Fedora is already contemplating
moving to GRUB2, but, with regard to btrfs, there is, naturally, a
catch. As was discussed in this article
last December, GRUB2 is licensed under GPLv3, while the btrfs code is
GPLv2-only. As has been done with ZFS, getting btrfs support into GRUB2
would require relicensing some of the code to GPLv2+. There are now enough
contributors to btrfs to make that relicensing an interesting problem, but
it is probably still feasible at this point.
Another potential issue is that the developers of Anaconda (the Fedora
installer) have complained that they
already have a lot of things to work on for the Fedora 16 release.
They don't relish the idea of more work, but, according to Chris Lumens,
"perhaps we can find some time somewhere." Simply installing
to btrfs should be a relatively easy change; reworking volume management to
be done within btrfs sounds like rather more work.
Jon Masters opposed the idea of switching
away from LVM, saying:
Yes, BTRFS can do a lot of volume-y things, and these are growing
by the day, but I don't want my filesystem replacing a full volume
manager and I am concerned that this will lead to less testing and
exposure to full LVM use within the Fedora community.
He did not find much support on the list, though; most participants in the
discussion seem interested in pushing forward and using the interesting
features that btrfs has to offer. Lennart Poettering would like to take things further by splitting
the installed drive into three subvolumes, one of which (holding the root
would be mounted read-only. This scheme would separate the system software
from user files and protect the system from changes most of the time, but
there would be no need to worry about filesystem sizing since btrfs can
expand any of the subvolumes when needed.
That, of course, would be a significant change; having to remount the root
filesystem for write access to install an update or make a configuration change could
get old relatively quickly. But it could also improve the security of a
running system and may be a good configuration for a number of
environments. The ability to take snapshots of the root partition and roll
the system back in case of trouble would be a nice added bonus.
The one other thing to be kept in mind is that btrfs, despite the speed
with which it is maturing, will certainly have a surprise or two in store
for its users still. Such is the nature of a new filesystem. But that is
also the nature of free software: at some point widespread real-world
testing is required to shake out the last round of bugs. Fedora seems like
it could be a good place for this level of testing. Whether the ambitious
Fedora 16 target will be met remains to be seen, but, if a btrfs
default does not happen then, it can probably be expected soon thereafter.
to post comments)