Re: [PATCH RFC 00/30] Ext4 snapshots - core patches

["Amir G." <amir73il@users.sourceforge.net>]

On Tue, Jun 7, 2011 at 7:54 PM, Josef Bacik <josef@redhat.com> wrote:
> On 06/07/2011 12:46 PM, Amir G. wrote:
>> On Tue, Jun 7, 2011 at 6:26 PM, Josef Bacik <josef@redhat.com> wrote:
>>>
>>> I probably should have brought this up before, but why put all this
>>> effort into shoehorning in such a big an invasive feature to ext4 when
>>> btrfs does this all already?  Why not put your efforts into helping
>>> btrfs become stable and ready and then use that, instead of having to
>>> come up with a bunch of hacks to get around the myriad of weird feature
>>> combinations you can get with ext4?
>>
>> Hi Josef,
>>
>> I understand the bitterness in btrfs community regarding ext4 snapshot
>> feature. You might say the same things about ext4 64bit feature.
>> I think it is not up to us to decide how it rolls. it's the users
>> and companies involved that dictate where the development happens.
>>
>
> Oh don't misunderstand me, I'm not bitter.  It just seems like this is a
> lot of work for something you get for free with btrfs.  A lot of work
> which I don't really think is justified when it comes to ext4.
>

Bitterness was a poor choice of expression.
Let me rephrase myself: I understand the wish of the btrfs community
that ext4 development would be focused on stabilization only
and that more developers would invest their time on stabilizing and
enhancing btrfs.

But there's the perfect world where everyone has migrated to btrfs
and there's real life, where sys admins are still hanging onto
ext3...

>> I like the answer that Ted once replied to the old btrfs vs. ext4 question:
>> competition is good because it makes us modest.
>>
>> I believe there is room in the future for both fs's, even with
>> similar features in both.
>>
>>
>>
>>>
>>> The wonderful thing about ext4 is its a nice basic fs.  If we're going
>>> to start doing lots of crazy things, why not do them to the fs that
>>> isn't yet in wide use and can afford to have crazy things done to it
>>> without screwing a bunch of users who already depend on ext4's
>>> stability?  Thanks,
>>>
>>
>> As I see it, stability is the *only* advantage of ext4 snapshots over btrfs
>> even though the snapshot feature is new and not stable, you still
>> have the good olf e2fsprogs tools that can get you out of any mess.
>> specifically, fsck -x will discard all snapshot files and make your ext4
>> fs clean and stable again.
>>
>> The repair tool is one thing that btrfs is still lacking, so I back CTERA's
>> decision to progress to ext4 with snapshots and not to btrfs on a
>> production system.
>>
>
> Sure, if you had spent time on a fsck tool for btrfs you would be done
> by now ;).

Touche ;-)

However, one cannot fast forward 20(?) years of stabilization
of the extended fs on-disk format checking tools.
More over, I think there is a reason, beyond not finding one
developer, why btrfs repair tools have not been written yet.
The degrees of freedom in the rigid extended fs format allows fsck
to be very effective in rescuing most of the fs.
Btrfs, being a much bigger hammer that it is, with everything is a tree
and all, has more degrees of freedom, which makes it hard for
any repair tool (or sysadmin) to make the right decision.
And the fact that ext4 snapshots (almost) doesn't change the extended
on-disk format, because snapshot files are posing as regular sparse
files, is it's strongest (well only) advantage over btrfs at the
moment.

> I feel that ext4 is becoming a dumping ground for every ones
> pet project which is resulting in this weird frankenstien like fs that
> is growing organically, rather than a great, stable and all around
> useful file system.  Rather than cramming more crap into it, maybe we
> should evaluate whether the work is useful in the first place with
> things like btrfs or the dm snapshotting stuff exist.  Thanks,
>

And how exactly will we be making this evaluation?
There is no clear value for 'stable' that we can be used to compare
the alternatives.

Cheers,
Amir.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html