Plans for BTRFS in Fedora

Jon Masters jonathan at
Wed Feb 23 16:41:49 UTC 2011

On Wed, 2011-02-23 at 07:15 -0500, Josh Boyer wrote:
> On Tue, Feb 22, 2011 at 10:25 PM, Jon Masters <jonathan at> wrote:
> > On Tue, 2011-02-22 at 14:51 -0500, Josef Bacik wrote:
> >
> >> 2) Fedora 16 ships without LVM as the volume manager and instead use
> >> BTRFS's built in volume management, again just for the default.
> >
> > In my personal opinion, this is a poor design decision. 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. Instead, I'd like to counter-propose
> > that everything stay exactly as it is, with users being able to elect to
> > switch to BTRFS (sub)volumes if they are interested in doing so.
> >
> > Should the switch to BTRFS by default happen, this will be one more
> > thing I will have to fix immediately during installation. The list grows
> > longer and longer over time - please don't make this change.
> You seem to spend a lot of time during your installs undoing all the
> new things that were done for the release.  Perhaps a rapid changing,
> bleeding-edge distribution isn't quite suited to your needs.  Maybe
> you would be more comfortable with Debian or CentOS?

I'll bite. I am, indeed, a fan of various Enterprise Linux distributions
and I make no pretense that I am not. I do run an Enterprise Linux on
one desktop, and it's also true that I intentionally run my primary
desktop several Fedora releases behind so as to avoid many of the
problems I see from some of these changes. However, I also run more
recent Fedora releases, and on those releases, I typically have to undo
changes such as the one originally being proposed (replacing LVM).

Again, I feel the solution is to have a Fedora architect whose role is
to realize the problems caused by seemingly isolated changes, and stop
them from propagating. You don't just replace years of UNIX (or Linux)
history/heritage overnight without bothering a chunk of the users.


More information about the devel mailing list