Re: [Ext2-devel] Re: [PATCH] concurrent block allocation for ext2 against 2.5.64

[Daniel Phillips]

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