Re: RAIDFrame Issues on 3.2

On Mon, 13 Jan 2003, Scott Wells wrote:

> I'm using RAIDFrame, both RAID 1 & 5, on 3.2 with all patches applied

> Has anyone else expereinced any issues with RAIDFrame on 3.2?

I have experienced similar issues. I have found that 'raidctl -u' invariably causes a kernel panic like the one you describe, and a 'raidctl -R' usually has the same effect if used more than once between reboots.

I found a message in the archives describing what sounds like the same problem:
 http://marc.theaimsgroup.com/?l=openbsd-misc&m=103833892014496&w=2 And a reply which gives some insight into a possible cause:  http://marc.theaimsgroup.com/?l=openbsd-misc&m=103903524029246&w=2

For me these issues are non-critical, since I can't unconfigure my array anyway (/ is mounted on it) and I can reboot before or after using 'raidctl -R'. I haven't yet had any crashes when just running with RAID normally, although it isn't very comforting to know that RAIDframe has issues like these...

I have a serial console working and know how to reproduce the panics fairly consistently, but I haven't got around to submitting a bug report yet. I should be able to do so in the next few days.

> I'm not running a GENERIC kernel, since I've patched, enabled RAIDFrame

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related openbsd.org Links advocacy announce bugs ipv6 misc ports ports-changes security-announce smp source-changes tech Request more information about Pantek

I am also using a Promise controller (FastTrak100 TX2) which needed a patched kernel, but the same problems occur using my motherboard's IDE controller and a 3.2-release kernel with the GENERIC configuration plus RAIDframe enabled.

> The thing I really don't like is it takes about 8 hours to get this

Rewriting parity on my 60GB RAID 1 array takes at least around an hour. A workaround for this problem for RAID 1 arrays I was considering (not sure if it would be appropriate for RAID 5) is to automatically fail one drive before fsck at startup so there is no risk of inconsistency, then reconstruct later. However, you temporarily lose fault tolerance.

A more desirable solution might be to have RAIDframe enter a degraded mode if the parity is dirty on startup where a read to any block of data first triggers a parity rewrite of that block. You lose performance until a full parity rewrite has been completed (which can be done whenever convenient), but at least you can be up and running straight away with no risk of further data corruption.

Alex Received on Tue Jan 14 08:00:08 2003