On Tue, Jul 20, 2010 at 4:12 PM, Amir G. <amir73il@xxxxxxxxxxxxxxxxxxxxx> wrote: > On Tue, Jul 20, 2010 at 6:38 PM, Jan Kara <jack@xxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
