Re: safe segmenting of conflicting changes

[Doug Ledford <dledford@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3014 bytes --]

On 04/26/2010 02:43 PM, Phillip Susi wrote:
> On 4/26/2010 2:05 PM, Doug Ledford wrote:
>> So, the point of raid is to be as reliable as possible, if the disk that
>> was once gone is now back, we want to use it if possible.
> 
> No, we don't.  I explicitly removed that disk from the array because I
> have no wish for it to be there any more.

Then you need to remove the superblock from the device.

>  Maybe I plan on using it in
> another array, or maybe I plan on shreding its contents.  Whatever I'm
> planning for that disk, it does not involve it being used in a raid
> array any more.

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.

>> The problem is the cause of this thread, and it's a bug that should be
>> fixed, it should not cause us to require things to have an explicit
>> --add --force to use a previously failed drive.  This is a case of
> 
> Then when the drive fails it should only be marked as failed, not also
> removed.  If I manually remove it, then it should stay removed until I
> decide to do something else with it.

As above, removed is a matter of state and simply means that the device
is no longer being held open by the raid device (aka, the device is no
longer a slave to the raid array).

>> The md raid stack makes no distinction between explicit removal or a
>> device that disappeared because of a glitch in a USB cable or some such.
>>  In both cases the drive is failed and removed.  So the fact that you
> 
> Then that's the problem.  If it fails, it should be marked as failed.
> If it is removed, it should be marked as removed.  They are two
> different actions, that should have different results.  Why on earth the
> two flags seem to always be used together is beyond me.

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.

And there in is the reason that you must go through both states in order
to remove a drive.  The first state, Failed, is what stops commands from
going to the drive, and the second state, Removed, is what actually
removes the dead drive from the array.  We don't allow you to remove a
live drive from the array.

Now, as those are both states, and not causes or intents, it is the
removing of the superblock that signifies intent that a drive should no
longer be part of the array.

-- 
Doug Ledford <dledford@redhat.com>
              GPG KeyID: CFBFF194
	      http://people.redhat.com/dledford

Infiniband specific RPMs available at
	      http://people.redhat.com/dledford/Infiniband


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]