On Fri, 09 Jun 2006 13:07:37 -0400 Jeff Garzik <jeff@xxxxxxxxxx> wrote: > I would propose the obvious... 'cp -a ext3 ext4', apply the extent and > 48bit patches, and then do the obvious search-n-replace. Most of ext3 is JBD. At least, in terms of complexity. And I don't think there's anything in this proposal which affects JBD, apart from changing the blocksize. Cloning JBD for this exercise would, I suspect, be the wrong thing to do - the two clones would be pretty much identical, apart from some scalar types. I did suggest a couple of years ago that we should clone the ext3 part and have both ext3 and ext4 use the same JBD layer - I don't know what happened to that idea. There has been steady, cautious but significant improvement happening in ext3 over the past few years. I'd expect that to continue, although perhaps at a lower rate. Having to apply the same changes to two filesystems would be an obvious loss. It comes down to looking at the patches, and I haven't done that in quite some time. Ideally the new functionality would all be under CONFIG_foo, but I do not know if that is being proposed here? > We need to draw a line in the sand. If we don't, no one ever will. You speak as if this is something which has happened before, or that it will happen again. All that being said, Linux's filesystems are looking increasingly crufty and we are getting to the time where we would benefit from a greenfield start-a-new-one. That new one might even be based on reiser4 - has anyone looked? It's been sitting around for a couple of years. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html