Re: raidframe fun

[Greg Oster <oster%cs.usask.ca@localhost>]

On Fri, 16 Aug 2013 22:30:58 +0100
Patrick Welche <prlw1%cam.ac.uk@localhost> wrote:

> On Fri, Aug 16, 2013 at 03:22:28PM -0600, Greg Oster wrote:
> > > 
> > > They didn't quite find each other again...
> > 
> > Right.. so the question is why?  This is not supposed to happen (and
> > the only way I've ever seen it happen before is if a User gets
> > playing tricks with the raid devices and attempts to re-combine
> > components after they've been configured to different RAID sets...)
> 
> So strictly those 2 disks were the only 2 disks in a functioning
> NetBSD box, they were then added to another box which also had a
> raid array, at which point I had kern/38241 _kernel_lock: spinout
> fun, and then loads of reboots failing to get kgdb to work.  It is
> only just now after a boot -1 that I actually got past the kernel
> panic, and this is what I saw. I haven't been in a position to play
> tricks yet... There is an outside chance that they may have met
> seatools, but I think that those were other disks...
> 
> BTW I don't think the data on those disks is worth worrying about,
> but I'm happy to do a bit of debugging with you if you think there
> is something to be fixed...

I don't think seatools would have done anything... what likely happened
was that the 'other box' with a RAID array likely had a raid0... that
would mean that the 'newly introduced disks', which also likely had
been raid0 at last configuration, would have auto-configured to raid9
(or whatever the highest raid available might have been).  If only one
of them got configured, and somehow the label got written back out with
the 'new raid id', then the raid ids would get out-of-sync and that
would make raidframe think that they were from different raid sets.
You probably would have been ok had both of them gotten re-configured,
but it's my guess that only one got done before the panic, at which
point things are badly messed up.

Someday perhaps Someone(tm) will add UUIDs to the component labels and
we can get rely on just that... 

Later...

Greg Oster