"Jeff Quast" writes: > > My first few months with raidframe caused many kernel panics. With 30 > minutes of parity checking, this was a difficult learning experience. > I was initialy led to beleive that raidframe was hardly stable (and > therfor disabled in GENERIC). > > However, as I gained experience with raidctl and raidframe, and traced > the panics to code level, I almost always found the panics were caused > by my misuse or misinterpretation of raidctl(8). A small book could > probobly be written on the many different situations you can find > yourself in with raidframe. > > I havn't had a kernel panic for a long time, and have had 3 disks fail > since on a level 5 raid without issue reconstructing, changing > geometry, etc. If memory serves me, I may have reconstructed a mounted > raidset, though given the choice, I certainly wouldn't.
RAIDframe was built to allow reconstructing a mounted RAID set... in fact, it goes to a lot of trouble to allow that to happen properly... The only 'problem' you might notice would be a performance degredation for both the rebuild and any user IO taking place... > All in all, I find kernel panics with raidframe is just its way of > saying "Bad choice of arguments" :) RAIDframe in OpenBSD is somewhat lax about checking the input provided by raidctl... It works quite well if you don't tell it to do anything it's not expecting :-} (most (all?) of those problems have long since been cleaned up -- unfortunately not in the code base that's in OpenBSD though :( ) Later... Greg Oster
