Plans for BTRFS in Fedora

Simo Sorce ssorce at
Wed Feb 23 16:16:16 UTC 2011

On Wed, 23 Feb 2011 10:33:26 -0500
Josef Bacik <josef at> wrote:

> On Wed, Feb 23, 2011 at 10:19 AM, Dennis Jacobfeuerborn
> <dennisml at> wrote:
> > On 02/23/2011 03:27 PM, Josef Bacik wrote:
> >> On Wed, Feb 23, 2011 at 9:18 AM, John Reiser<jreiser at>
> >>  wrote:
> >>> On 02/23/2011 05:07 AM, drago01 wrote:
> >>>> Defaults should be chooses on the metric what provides the best
> >>>> experience for the users not based on "what we have been doing
> >>>> in the past" (i.e stagnation).
> >>>
> >>> *One* data corruption constitutes EPIC FAIL.  Btrfs is too young,
> >>> and will be for yet a while longer.
> >>>
> >>
> >> Well if data corruption is the test then we shouldn't be using Ext4
> >> either, there was one fixed as recently as the beginning of this
> >> month.  File systems are software like anything else, there will be
> >> bugs.  Off the top of my head I can think of 3 data corrupters
> >> we've had in 4 years of working on BTRFS, and they've all been
> >> hard to hit and have not to my knowledge been seen by users, only
> >> us developers in testing.  BTRFS is young, but we have to start
> >> somewhere.  Thanks,
> >
> > I'm actually not that worried about corruption as that is something
> > that can be fixed once discovered. What creeps me out about btrfs
> > at the moment is this:
> >
> >
> >
> > The fact that the FS needs manual rebalance operations and that
> > these can "take a while" (even tough this can be done online)
> > doesn't exactly make btrfs the ideal candidate for an end-user
> > desktop system that should pretty much be able to look after itself.
> > I'm actually quite interested in btrfs especially for servers
> > because of it's features but this problem really worries me.
> >
> Yes this is one of the more complicated areas of BTRFS and tends to
> blow up in our faces a lot.  That being said it's only a big deal if
> you tend to run your filesystem close to full a lot, which most people
> do not.  It is an area that we work very hard to make sure it's not a
> problem, hopefully we have eliminated all of the big problems and you
> should really only see ENOSPC when you actually fill up the disk.
> Thanks,

Sorry josef,
but I do that all the time with my Virtual Machines, as I
do not give them more space then strictly needed.

I did that to the point that I needed to uninstall a few devel packages
in order to upgrade from f14 to rawhide on a VM ...

I am, not sure how common it is on a desktop, just wanted to point out
it is a use case to be able to run with little disk at least for
development VMs. (I guess I can manually run whatever tool there, as
long as it is clearly recognizable when I need to do so).


Simo Sorce * Red Hat, Inc * New York

More information about the devel mailing list