Re: [PATCHES/RFC v1.0.12] e2fsprogs: Next3 patch series

[Greg Freemyer <greg.freemyer@gmail.com>]

On Tue, Jul 20, 2010 at 4:12 PM, Amir G. <amir73il@users.sourceforge.net> wrote:
> On Tue, Jul 20, 2010 at 6:38 PM, Jan Kara <jack@suse.cz> wrote:
>>> In fact, the posted patches are only the small patches to e2fsprogs.
>>> The more challenging job is the review of the Next3 snapshot patches,
>>> which apply on top of ext3 (or rather a forked branch of ext3 called next3).
>>> They are available for download at
>>> http://sourceforge.net/projects/next3/files/Latest%20patch%20series
>>> but I can also post them to the list if you like (about 40 medium size patches).
>>  Well, I can have a look at those patches. But I'd like to know what is
>> exactly your motivation - is it that you have some customers running with
>> this clone and want to upstream the fs, or is it that you'd like to
>> contribute the cool feature you've developped, or something else?
>
> contribute cool feature is the best match.
>
>> Because on this depends where we should go from the current situation...
>>  To state my position: I'm not willing to merge the feature into ext3
>> because it's basically in a maintenance mode so we don't accept larger
>> features to it anymore (for stability reasons).
>
> of course.
>
>>  You could, of course, copy ext3 code base and create a separate next3
>> filesystem. But such code duplication would be generally frowned upon and I
>> personally wouldn't like to take the burden of maintaining such code so
>> you'd have to do it. Moreover you have to port all ext3 fixes to your code
>> and you have a problem that as time progresses, new features are added to
>> ext4, not ext3, so I think it would be less and less attractive to run
>> Next3 instead of ext4... So this doesn't seem like an ideal solution either.
>
> you are not the first to tell me that the fork from ext3 is not a good idea.
> I agree that in the long term, Next3 as a file system driver has no place,
> but for practical reasons, I needed to create a separate file system driver,
> so people will be able to use the new feature without patching ext3 during
> the long time it will take me to merge the feature to ext4.
>
>
>>  For future, the most promising to me would be to change the
>> implementation to work with ext4 and merge it there. I understand there are
>> technical issues with this and I'm not sure how hard they would be to
>> solve. But for me as a filesystem developper this would seem like a
>> direction where it's worth to invest some time and energy and I can help
>> with that (and I believe other ext4 developpers might lend a hand as well).
>>  Just my thoughts...
>
> and the first step towards getting the snapshot feature into ext4 is
> for some ext3/4
> developers to review the patches, so I will have someone (rather some than one)
> with whom I can discuss the merge issues.
> I actually proposed the next3 merge as a topic for LSF, but that
> didn't get much attention.
>
>> Anyway, I've added to my todo an item to have a look
>> at your patches so that I have better idea what we are discussing about.
>
> That would be great.
> If you like, we can schedule a call after you've gone through some of
> the patches/docs.
> I have done this with Ted and I think it's a good way to get started.
> if you haven't looked at http://sourceforge.net/apps/mediawiki/next3/
> that would be a good place to start (also links to the snapshots design paper)
>
> Thanks for taking an interest,
> Amir.

So are you just asking for comments right now, or are you asking that
the e2fsprogs patches get applied?

Maybe a separate e2fsprogs branch for next3 should be created like
there was for the 64-bit patches?  (That would be Ted/Jan's call, not
mine.)

Greg
--
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