On Wed, Feb 23, 2011 at 10:19 AM, Dennis Jacobfeuerborn <dennisml@xxxxxxxxxxxx> wrote: > On 02/23/2011 03:27 PM, Josef Bacik wrote: >> On Wed, Feb 23, 2011 at 9:18 AM, John Reiser<jreiser@xxxxxxxxxxxx> 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. Thanks, Josef -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel