On 04/26/2010 01:48 PM, Phillip Susi wrote:
> On 4/26/2010 12:59 PM, Doug Ledford wrote:
>>> This goes ahead and adds the disk back to the array, despite the fact
>>> that it has been explicitly removed.
>>
>> Of course it does. You've just explicitly readded it, which is no
>> different than your explicit removal. Mdadm honors both.
>
> No, --incremental is automatically invoked by udev to scan disks as they
> are detected and try to assemble them. It isn't an explicit --add
> operation.
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.
>>> Whether or not the superblock on sdb is updated when it is removed,
>>> --incremental should NOT use it as long as mdadm -D /dev/md0 says that
>>> disk is removed, at least not use it in /dev/md0.
>>
>> Why not? It's not like it uses it without correcting the missing bits
>> first. My guess is that you've either A) got a write intent bitmap or
>
> Actually under the right circumstances it DOES use the second disk's
> incorrect data without correcting it first,
A problem for which I suggested a specific fix in another email.
> and if it does overwrite it,
> that causes data loss so should not be done without an explicit --add
> --force. The fact that this happens is the entire reason for this thread.
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
reacting to a bug by disabling a useful aspect of the stack instead of
simply fixing the bug IMO. When the raid stack thinks that things are
out of sync, it doesn't automatically do anything bad. The real bug
here is that there is a way to get things out of sync behind the raid
stack's back.
> Whether or not it can be added safely, the disk has been explicitly
> removed so automatically adding it back is not acceptable.
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
draw a distinction is irrelevant until such time as the raid superblocks
are changed to be able to encode the cause of a device being removed in
addition to the fact that it simply was removed.
--
Doug Ledford <dledford@xxxxxxxxxx>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
Attachment:
signature.asc
Description: OpenPGP digital signature
