Plans for BTRFS in Fedora

Josef Bacik josef at
Wed Feb 23 15:33:26 UTC 2011

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.


More information about the devel mailing list