Messages in this thread |  | | | Date | Fri, 09 Jun 2006 13:48:02 -0400 | | From | Jeff Garzik <> | | Subject | Re: [RFC 0/13] extents and 48bit ext3 |
| |
Andrew Morton wrote: > On Fri, 09 Jun 2006 13:07:37 -0400 > Jeff Garzik <jeff@garzik.org> 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.
The JBD API is reasonably distinct, so IMO this would be a logical next step. I would hope they could use the same JBD, so, I strongly agree...
> 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.
I disagree completely... it would be an obvious win: people who want stability get that, people who want new features get that too.
> 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.
reiser4 actually has this same problem, but worse. It has pluggable metadata even to the point of supporting plugin-style metadata development.
If we can successfully devolve a filesystem to metadata and algorithm plugins, that should be done at the VFS level, and not called "reiser4".
But in the absence of a different VFS API, I think it is the most practical of all the options to open the floodgates to ext4 rather than ext3.
Jeff
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |