lkml.org 
[lkml]   [2003]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [Ext2-devel] Re: [PATCH] concurrent block allocation for ext2 against 2.5.64
Date
On Fri 14 Mar 03 00:56, Andreas Dilger wrote:
> There was a desire to keep ext2 small and simple, and ext3 would get the
> fancy high-end features that make sense if you have a large filesystem
> that you would likely be using in conjunction with ext3 anyways.
>
> It does make sense to test this out on ext2 since it is definitely easier
> to code for ext2 than ext3, and the journaling doesn't skew the performance
> so much. Of course one of the reasons that ext2 is easier to code for is
> exactly _because_ we don't put all of the features into ext2...
>
> Comments on the code inline below...

Ext3 is getting to the point, or has already gotten to the point, where it's
so reliable that it's reasonable to call it Linux's new native filesystem. At
this point, Ext2 can become more of a crucible for new techniques, hopefully,
techniques that simplify things, shorten up data paths, clarify the code,
make it more parallel and so on. For example, I can't help thinking that's
there's some fundamental improvement possible to the truncate path (hmm, I
wonder if I'm giving Alex new ideas...) and that proving such a thing out in
Ext2 first would make a whole lot of sense.

I do intend to pick up the Ext2 HTree patch again in due course and attempt
some simplification of it, as well as working on the outstanding
optimizations, i.e., improved inode allocation and delete coalescing. HTree
is an example of a feature that adds a few K of code, but in my opinion it's
worth it in order to match up better with the Ext3 feature set. Besides,
Ext2 is still quite attractive as a host filesystem for NFS export, and would
be still more attractive with the directory index.

(By the way, on the HTree simplification front, there's a whole lot of
forward declaration cruft that can go away as soon as CONFIG_EXT3_INDEX
is declared to be always on.)

So anyway, the point you were making and that I agree with, is that Ext2 is
growing into the role of experimental filesystem; Ext3 is now the stable
filesystem. Hopefully, the experiments will make Ext2 smaller, cleaner and
at the same time, more powerful, over time. Sort of like the role that RAMFS
plays: besides being useful, Ext2 should be thought of as a showcase for best
filesystem coding practices.

Regards,

Daniel
-
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: 2005-03-22 13:33    [W:0.073 / U:0.744 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site