> > It wasted 2900 seconds of CPU time on Linux. Let me guess: this was done
> > inside the function strcmp().
>
> Nope. ext3 and ext2 directories use the traditional first-fit
> search-from-start for directories. So adding 200k files to
> a single directory is pathological.
>
> > There are ~ 5 different filesystems on Linux, but none if the projects seem
> > to care about the code outside the FS low level code. I suspect, that
> > this is not any better if you use reiserfs.
> >
> > Solaris and FreeBSD put all the effort into one filesystem trying to make
> > it as good as possible. In Linux, it seems that nobody prooved the overall
> > concept of the kernel.
>
> Apply http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.25/ext3-htree.patch
> to your 2.5.25 tree, mount with `-o index' and enjoy watching ext3 eat
> Solaris and FreeBSD's lunch.
I didn't benchmark, but how much lunch is left? UFS_DIRHASH was
introduced into FreeBSD by Ian Dowse a year ago (released in FreeBSD
4.4), and activated in FreeBSD 4.5's generic table. In case you missed
that, FreeBSD 4.6 is out since about four weeks.
options UFS_DIRHASH #Improve performance on big directories
http://www.freebsd.org/releases/4.4R/relnotes-i386.html#AEN197
http://www.freebsd.org/releases/4.5R/relnotes-i386.html#AEN250
http://www.cnri.dit.ie/Downloads/Malone_2001_bsdcon.pdf
The latter document by David Malone (November 2001) claims "MH 33 k
files create: 70s to 2.5s, pack: 240s to 2.5s, rm: 4.7s to 2s."
So might be ext3fs comes just in time for dessert, or is htree so much
faster than UFS_DIRHASH?
-- Matthias Andree - 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/