Simon Burge writes:
> 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. 

That's a lotta disk for one of those machines, no? :)

> 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 %C
> PU 
> 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. 

That's about right... You'll notice a performance improvement for writes 
with a -current kernel..

> 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 :).

:-) Just run 'raidctl -i raid0' in the background.  You can still fsck, 
mount, use, etc. the filesystem while the parity is begin computed -- it's 
just that it's somewhat riskier, of course.  You actually don't want the raid 
set to be operating in degraded mode before parity is computed, as degraded 
mode implies that you may be using the parity bits to compute data bits -- but 
at that point you don't know that the parity bits are good! (if you knew the 
parity bits were good, you wouldn't be looking to recompute them :) ).
While the parity is begin recomputed, the real data blocks will be being read 
on reads, and on writes, the real data blocks will be written, and the 
associated parity blocks will be updated as well.  The parity re-write can 
operate independent of all of this, and can do it's job even if you're working 
with the RAID set.
 
> In a nutshell - so far, so good :-)

Cool :)

Later...

Greg Oster