Hi,
I've played a bit with raidframe today. Here are a few results:
I used 3 Ultra-wide FUJITSU 8Gb disks on a PII-400Mhz. 2 of the disks where on
a ahc2940, the last one on a ncr875.
Here are the results I got from bonnie:
sd5 is the result for a single drive on the ahc, ccd0 and ccd1 for a ccd
between the 2 drives of the ahc with an interleave of 32 and 171,
respectively; and raid5_0 and raid5_1 for a raid5 array with the 3 drives,
with an interleave of 32 and 171 respectively. raid4_0 and raid4_1 are
the same tests for a raid4 array.

              -------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
sd5       100  8320 36.0  8074  7.4  1302  1.8  8332 37.8  8319  6.7  89.0  1.1
ccd0      100  2335 10.4  2335  2.3  1553  1.8 10805 50.6 11441  7.1 117.5  1.3
ccd1      100  5936 25.9  5691  5.2  3210  3.8 13823 63.6 14734  8.6 114.9  1.2
raid5_0   100  2218 11.7  2137  3.8  1264  2.4  5961 29.7  5152  4.5 114.0  2.1
raid5_1   100  2003  9.7  1573  2.2   773  1.0  7417 35.4  8325  5.9 106.5  2.0
raid4_0   100  1912 10.1  1981  3.6  1308  2.5 10859 53.8 11625  9.9 115.0  2.1
raid4_1   100  1612  7.8  1287  1.8  1543  2.1 10498 49.9 15265 10.7 112.8  2.1

raid5 seems to suffer from bad performances, but I already noticed this
with "external" raid5 arrays. With raid4 it seems possible to achieve
performances close to ccd for reading, but writing is worse than
raid5 ...

But I've been disapointed by the behavior of our scsi drivers: to test the
raid5 behavior, I starded switching off and on the disks. The ahc driver
doesn't like this very much: when I power back the drive, the console if
flooded with message likes:
target 4 synchronous at 20.0MHz, offset = 0x8
and the bus is hung.
Using scsictl to probe a disk which was not powered at boot time doesn't
seems to initiate sync/wide negotiation; at last there's no messages and
the performances are not as good as with a drive probed at boot time.
Powering off and on a disk on the ncr bus has quite the similar effect: there's
and error message from the ncr driver, it seems to issue a bus reset and
the bus is hung.

These behaviors prevent any king of hotswapping, and raidframe would be much
more useable if these were fixed. The ahc case seems to be the more simple
to fix. Maybe a look at the FreeBSD driver would help ?
Unfortunably I only have temporary access to this test box, so I
will not be able to address this in the near future.

Now a few comments about the degraded mode of raidframe:
After powering off one of the drive, the scsi command timed out and
the console got flooded with messages like:
Nov 25 13:06:26 pr7 /netbsd: DEAD DISK BOGUSLY DETECTED!!
Nov 25 13:06:26 pr7 /netbsd: [0] node (Rop) returned fail, rolling backward
Nov 25 13:06:26 pr7 /netbsd: [0] node (Rrd) returned fail, rolling backward
Nov 25 13:06:26 pr7 /netbsd: [0] DAG failure: w addr 0xe2b0 (58032) nblk 0x80 (1
28) buf 0xf6268000

I guess these comes from raidframe. Marking the component as failed doesn't
seem to help. The 2 other disks have a lot of activity, but the bonnie process
I had is stuck on "getblk".
After a reboot,  raidframe cam up with a component marked "failed" (the
disk was still off). I powered on the disk and issued a rescan of the bus.
Then I found no way to ask raidframe to recontruct the data of this disk.
I had to mark it as spare in my config file, unconfig/reconfig raid0
and issue a raidctl -F. I think it would be nice to be able to ask raidframe
to rebuild a disk directly, for configurations without spares.

When configuring raid0 with a non-existent spare, the config fails, but
the component are still marked busy. After fixing the config file,
any raidctl -c would fail because of this. I had to reboot.
Also, I think a 'raidctl -r' should immediatly fail on a device with failed
components. For some reason, the box gets hung for a few second when doing
this.

However, even with these SCSI issues, raidframe looks really usable.
Good work !

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
--