lkml.org 
[lkml]   [2006]   [Jun]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
DateFri, 09 Jun 2006 13:48:02 -0400
FromJeff Garzik <>
SubjectRe: [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/

\
 
 \ /
  Last update: 2006-06-09 19:50    [from the cache]
©2003-2010