Slow FFSv1 file system performance

[Christopher Berardi <cberardi%natoufa.com@localhost>]

I wrote a test on a Windows platform to see how it handled a large number of 
directories (~16M). The basic structure was three levels of directories, each
named with a two digit hex value. For example, one such path would be 
$root/fa/02/6b. All of the directories were created, but I ended up frying my
hard drive (I think it was on its last legs anyway).

So, I decided to test it on a spare NetBSD box I had. I ran it and it never 
completed, running out of inodes after about ~3-4M directories. I understand
that and I didn't create the file system initially with the thought of having
so many directories.

The main concern I had was speed performance. I thought that surely FFS would
be faster than the Windows NTFS, especially since my NetBSD box has better 
hardware (faster CPU, more RAM, larger and faster hard drive, etc.). But, much
to my chagrin it was considerably slower. It was at least 4 times slower than
the Windows version. While the Windows version took about 4 hours to create
all the directories, it took the NetBSD version over 4 hours until it ran out
of inodes at less than 25% of the directories created. It also took over 9
hours to remove them all (that may be due to the recursive nature of the rm -r
command). 

The Windows version was written in C# with a simple loop and each time the 
iterator value was converted to a directory path and a call made to the 
Directory.Create() function. The NetBSD version was written in C utilizing 3
loops (one for each directory level), several string.h functions and mkdir(2)
to actually create the directory. I would have thought that just being in C as
opposed to C# and .NET would have made it faster, but I guess I was wrong.

Any ideas on why the lack of performance? 

-- 
Christopher Berardi
http://www.natoufa.com/

Be still, and know that I am God (Psalms 46:10)