Plans for BTRFS in Fedora
ssorce at redhat.com
Wed Feb 23 16:16:16 UTC 2011
On Wed, 23 Feb 2011 10:33:26 -0500
Josef Bacik <josef at toxicpanda.com> wrote:
> On Wed, Feb 23, 2011 at 10:19 AM, Dennis Jacobfeuerborn
> <dennisml at conversis.de> wrote:
> > On 02/23/2011 03:27 PM, Josef Bacik wrote:
> >> On Wed, Feb 23, 2011 at 9:18 AM, John Reiser<jreiser at bitwagon.com>
> >> 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:
> > https://btrfs.wiki.kernel.org/index.php/FAQ#Help.21__Btrfs_claims_I.27m_out_of_space.2C_but_it_looks_like_I_should_have_lots_left.21
> > 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.
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