Subject: Re: raidframe consumes cpu like a terminally addicted
To: Matthias Buelow <mkb@mukappabeta.de>
From: Charles M. Hannum <abuse@spamalicious.com>
List: netbsd-users
Date: 04/30/2001 17:25:40
On Tue, May 01, 2001 at 02:09:16AM +0200, Matthias Buelow wrote:
>
> ncg     4375    ncyl    139970  size    17916160        blocks  17286075
> cpg     32      bpg     512     fpg     4096    ipg     1024

So, pay special attention to ncg and bpg.  Given that your directory
only contained 935 subdirectories, and ncg is so huge, there's a good
chance that each of the subdirectories is in a separate cylinder group.

Now consider that fts(3) is entirely synchronous/sequential.  Let's do
a back-of-the-envelope calculation:

average seek time between CGs: 6ms
number of seeks to read all the inodes: 935
time just to seek: 6*935ms=5.61s

Now, consider that each of these reads has to touch multiple disks and
be destriped.  Also consider head load/unload time and rotational
latency.  (Seek time is sort of misleading.)

Also consider that this probably blows your cache into little tiny bits
each time -- unlike the repeated tests on the `single disk', which is
all going to get cached.

I don't think it's any surprise that it takes as long as it does.

Sounds like yet another good reason to cluster directories, though.
Wasn't someone working on this (finally)?