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)?