Chris Jones writes:
> >>>>> "Greg" == Greg Oster <oster@cs.usask.ca> writes:
> 
> >> * Doing anything with the RAID array seems pretty slow.  It took
> >> over two hours to initialize the parity information for a RAID5
> >> array across three 9G disks.  It's currently doing a 17GB newfs,
> >> and it looks like that will take about an hour by the time it's
> >> done.
> 
> Greg> Given that it's got to read 18 GB of data and write 9GB of data,
> Greg> it's going to take a little while to re-write parity, even with
> Greg> fast disks...  I'm not sure if 2 hours is unreasonable or not,
> Greg> as I've never worked with a RAID set that big with RAIDframe,
> Greg> nor have I used UW controllers/drives (yet). (I've thought about
> Greg> how nice it would be, but that's it :) )
> 
> Yeah, it's a good point.  But once the filesystem is there, it writes
> files at about 1.7 MB/s.  This seems really slow to me.  Of course, I
> might just have over-inflated expectations, but UW SCSI is supposed to
> be fast.

Ick... 1.7MB/sec does seem quite slow... 

I just built a RAID 5 set over 1 IBM disks and 1 HAWK (2 controllers, 
all fast-narrow drives, CPU is a P133) and got the following from Bonnie:

              -------Sequential Output-------- ---Sequential Input-- --Random--
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
          500   935 31.6  1206  8.6   910  5.8  2806 93.9  3960 13.8  36.1  5.3

which isn't exactly spectacular, but these arn't the world's speediest disks.
I'd have expected the faster disks to do better, even on a P120. 
(I've got an idea as to why this is slow, and it's related to a "fix" put into 
the driver to ensure that it doesn't try to eat up all the kernel memory (and 
thus panic the system).  I'll send you additional info in a separate email.)

> Greg> [snip]
> >> This is an i386, 1.4 system.
> 
> Greg> What CPU?
> 
> It's a Pentium 120MHz.  RAIDFrame isn't *that* CPU intensive, is it?
> I'll check in a few minutes here, I guess.  I can run top while doing
> stuff to it.

If you change a single bit on a stripe, it's got to do a minimum of 2 reads 
and 2 writes.  If your stripe width is 32 blocks (16K), it has to read 32K and 
write 32K, just to change 1 bit.  (never mind the filesystem overhead).
Yes, it can be CPU intensive, especially on slower CPUs.  

> Greg> It could also be that the stripe width (or sectors per stripe
> Greg> unit) are not optimal for those drives/your machine.
> 
> Yeah.  I was trying to avoid experimenting with it, but I guess that's
> what I'm going to do now.  I'll use small partitions, I think.  :)

Yup, small partitions for the experimentation are the way to go... 

Later...

Greg Oster