Greg Oster wrote:

> With whatever you decide, I'd be interested in hearing how it goes :)

Well, here's some initial results.  I've got a 5000/240, with 1 boot
RZ28 (2GB) disk, and another 11 RZ28s spread across two controllers in
a raid5 setup.  For now, I've decided not to have a hot spare, but will
when I find another disk.  The initial "raidctl -i raid0" took 2h33m57s,
and a "newfs -i 8192" took 19m26s.

Here's some bonnie times.  First, a ccd using 6 RZ28s on the same bus (under
NetBSD 1.3.1):

              -------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 
6#rz28    128  1540 99.1  3224 27.9  1741 28.4  1377 99.6  3652 33.9  76.0  8.4

and then some results on the new raid5 filesystem (NetBSD 1.4.1):

11#rz28    32   615 41.2   928 13.9   760 15.0  1200 97.7  3324 49.7  47.5 10.2
11#rz28   128   624 42.3   924 14.4   772 17.0  1175 97.6  3388 52.2  41.7  9.4

These aren't apples vs. apples numbers, but (as has been mentioned
before) write performance isn't too flash.  I'm not hugely worried about
this, as the box is serving an FTP site and is only connected with
10mbit ethernet.

My primary concern at this stage is the time it takes to rewrite the
parity.  Has any thought been given to backgrounding this process so
that the raid set operates in degraded mode until parity is recomputed?
(No I haven't read the RAIDframe papers yet :).

In a nutshell - so far, so good :-)

Simon.