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