On Mon, 23 May 2005, Arjan van de Ven wrote:
On Mon, May 23, 2005 at 03:02:23AM -0700, Dan Hollis wrote:
> On Mon, 23 May 2005, Arjan van de Ven wrote:
> > > Both.
> > > Its not just for large directories, reiserfs did much better with many
> > > small files too (typical of news and mailservers).
> > Hmm. that surprises me for htree enabled filesystems (note that if you
> > create an FS with an old distro and then put 2.6 on it it doesn't use
htree)
> Remember reiserfs was designed from the bottom up to work quickly with
> lots of _small files_. So it does what it was designed to do well. That
> this happens to be the typical workload of news servers and mailservers
> is a happy coincidence.
yet a design goal leads to a technological implementation, and I'm wondering
what is a causing factor for ext3 to not be roughly equally fast. ext3 with
htree should in principle not be bad at lots of small files. at all. There
is no inherent bias in ext3 towards bigger files (well except when you count
not having tail merging; tail merging will give you gain in the case of a
read-mostly lots-of-small-files case)
I think some of this has to do with the fact that ext3 is fundamentally a
very, very, very old filesystem. Its some of the oldest code still in the
kernel iirc. Some of the assumptions made in the original design may no
longer be so relevant over a decade later. ext2 was in use when everyone
was still on PIO and C/H/S :-) reiserfs by comparison is brand spanking
new.
I recall hearing something about a tailmerging patch for ext2/3 somewhere.
What happened to that?
-Dan