On Wed, 23 Feb 2011 10:33:26 -0500
Josef Bacik <josef(a)toxicpanda.com> wrote:
On Wed, Feb 23, 2011 at 10:19 AM, Dennis Jacobfeuerborn
<dennisml(a)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(a)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_o...
>
> 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.
--
Simo Sorce * Red Hat, Inc * New York