Re: safe segmenting of conflicting changes

[Phillip Susi <psusi@cfl.rr.com>]

On 4/26/2010 3:07 PM, Doug Ledford wrote:
> Then you need to remove the superblock from the device.

Why?  It has been removed.  In English removed means it is no longer
part of the array.  Elements which are not part of the array should not
be MADE part of the array just because they happen to be there.

Having to zero the superblock after failing and removing the drive is a
race condition with detecting the drive and automatically adding it back
to the array.  To properly remove the disk from the array the superblock
needs to be updated before the kernel releases the underlying device.

> The problem here seems to be an issue of expectations.  You think that
> "removed" is used as a flag to record intent, where as it actually is
> nothing more than a matter of state.

No, I don't think it has anything to do with intent.  I think that the
state of being removed means it is no longer part of the array.  It
sounds like your understanding of the state should be described in
English as detached or disconnected, rather than removed.

> Failed is also a matter of state.  It means the device has encountered
> some sort of error and we should no longer attempt to send any
> read/write commands to the device.  It is not a statement of *why* it's
> in that state.  The removed state indicates that the device has been
> removed from the array and is no longer a slave to the array.  Again, no
> indication of intent or cause, purely an issue of state.

Yes, it does not indicate why, nor do we care.  What we care about is
that the drive failed or was removed, so we should not be using it.  Why
bother recording that fact in the superblock if you're just going to
ignore it the next time you start the array?