From: Ric Wheeler <rwheeler@redhat.com>
To: "Amir G." <amir73il@users.sourceforge.net>
Cc: Ric Wheeler <rwheeler@redhat.com>, Andi Kleen <andi@halobates.de>,
tytso@mit.edu, linux-ext4@vger.kernel.org
Subject: Re: Introducing Next3 - built-in snapshots support for Ext3
Date: Sat, 08 May 2010 08:51:21 -0400 [thread overview]
Message-ID: <4BE55E49.5000006@redhat.com> (raw)
In-Reply-To: <AANLkTinbzARSNHOvMbRq7iKSZENKhnKYdKSq5IHvX_xs@mail.gmail.com>
On 05/08/2010 01:43 AM, Amir G. wrote:
> On Fri, May 7, 2010 at 11:25 PM, Ric Wheeler wrote:
>
>> On 05/07/2010 03:22 PM, Amir G. wrote:
>>
>>> In theory, it is possible to have 2 modes for Ext4 (extents or snapshots)
>>> and some would argue that it makes sense to do that.
>>> But I think that making that decision can be deferred to a later time,
>>> after people have experienced with Next3 and have decided if they
>>> would like to have
>>> the snapshot feature merged into Ext4 or not.
>>>
>>> Besides, it would take me a considerable amount of time to merge the
>>> snapshot feature into Ext4,
>>> and Next3 is ready to be used now.
>>>
>>> Amir.
>>> --
>>>
>>>
>> I think that the counter argument would be that moving features into ext3 is
>> probably the wrong thing to do.
>>
>> I don't think that anyone is in a huge hurry given that we have LVM based
>> snapshots with ext3 and btrfs snapshots around the corner. Probably this is
>> most interesting when done to the latest version of the ext family.
>>
>>
> This is a valid argument, but it is important for me to clarify a few
> issues regarding the statements above:
>
> 1. No features are added to Ext3, so there is no concern for the
> stability of Ext3.
> The feature is added as a new f/s, with the slight overhead of
> duplicate code in the
> kernel tree and an extra loadable module in the system.
>
> 2. From the user's point of view, there is not much difference between
> "mount -t next3"
> and "mount -t ext4 -o snapshots", because in both cases it would not
> be possible to
> mount ext4 with extents support on that volume before discarding snapshots and
> it will be possible to mount ext4 with extents support after
> discarding snapshots.
>
> 3. Next3 snapshots are much more scalable durable and efficient than
> LVM snapshots.
> These are some of the benefits of built-in snapshots support.
>
> 4. I do not want to restart the discussion about when btrfs will be
> production ready.
> As for Next3 stability, I think that with the help of the community,
> Next3 can be production ready within a matter of months,
> because the Next3 code religiously attempts to retain the stability of
> its ancestor Ext3.
>
> I dare you to prove me wrong ;-)
>
> Amir.
>
As Ted mentioned in his reply, the big concern is that you are forking
ext3 instead of adding a new feature to the end of the ext* family of
file systems.
Since we have multiple snapshot mechanisms in place already (not just
btrfs & lvm, but don't forget all of the builtin array snapshots), I
think that we are not in a hurry to get this done quickly. I would
strongly prefer we get this rebased onto the latest ext4 and resubmitted.
As far as proof goes, I think that the unfortunate burden of proof is on
your shoulders to prove to us that we should take and maintain those new
features given the often conflicting priorities :-)
Thanks!
Ric
next prev parent reply other threads:[~2010-05-08 12:51 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-18 15:41 Introducing Next3 - built-in snapshots support for Ext3 Amir G.
2010-05-03 9:47 ` Amir G.
2010-05-04 19:55 ` Andi Kleen
2010-05-05 1:03 ` Amir G.
2010-05-04 22:42 ` tytso
2010-05-05 2:05 ` Amir G.
2010-05-07 15:12 ` Andi Kleen
2010-05-07 19:22 ` Amir G.
2010-05-07 21:25 ` Ric Wheeler
2010-05-08 5:43 ` Amir G.
2010-05-08 11:48 ` Theodore Tso
2010-05-08 16:07 ` Amir G.
2010-05-08 17:25 ` tytso
2010-05-08 19:40 ` Amir G.
2010-05-09 2:25 ` Theodore Tso
2010-05-09 11:56 ` Amir G.
2010-05-15 6:14 ` Amir G.
2010-05-08 12:51 ` Ric Wheeler [this message]
2010-05-08 22:56 ` Amir G.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BE55E49.5000006@redhat.com \
--to=rwheeler@redhat.com \
--cc=amir73il@users.sourceforge.net \
--cc=andi@halobates.de \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.