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