Subject: Re: RAIDFrame: Reconfiguring an array
To: Frederick Bruckman <fredb@immanent.net>
From: Greg Oster <oster@cs.usask.ca>
List: netbsd-users
Date: 06/11/2006 16:22:06
Frederick Bruckman writes:
> 
> I was thinking of the common case where a drive goes away for
> a while, then comes back at the next reboot.  As it's already
> configured to be part of the set, parity will rebuild
> automatically. 

Ummm... "no".  If a drive goes away, and the kernel detects that when 
trying to write, then the component label(s) on the surviving drive(s) 
for that set will get updated.  The same thing will happen if the 
machine is shutdown properly -- "surviving" drives will have their 
component labels updated.

> I've always assumed there's a date stamp that
> tells raidframe which compenent is newer.  Is there?  It'd be
> nice to be able to see that date with "-g".

It's not a "date stamp" but a "modification counter".  Look for "Mod 
Counter" in the output of "raidctl -s raid0".  These modification 
counters are used in a voting fashion to determine what the correct 
count should be (highest counter value used in case of a tie).

So in the case where a disk "happens to go away, and then come back 
at the next reboot", the modification counter for the drive that 
'disappeared' should be 2 or 3 lower than the count for the good 
drive.  Since the rest of the component labels match up, the 
'disappearing' drive will be added to the set, but in the "failed" 
state.  Thus, the automatic parity rebuild will actually fail in this 
case.

Later...

Greg Oster