Subject: Re: raidframe on a pmax?
To: Simon Burge <simonb@NetBSD.ORG>
From: Greg Oster <firstname.lastname@example.org>
Date: 08/02/1999 09:04:01
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
> 6#rz28 128 1540 99.1 3224 27.9 1741 28.4 1377 99.6 3652 33.9 76.0 8
> 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
> 11#rz28 128 624 42.3 924 14.4 772 17.0 1175 97.6 3388 52.2 41.7 9
> 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 :-)