Re: safe segmenting of conflicting changes

[Doug Ledford <dledford@redhat.com>]

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

On 04/23/2010 02:18 PM, Phillip Susi wrote:
> After some more testing it seems the problems with --incremental are
> more deep and general.  I have found two steps that both appear to do
> the wrong thing:
> 
> mdadm /dev/md0 --fail /dev/sdb
> mdadm /dev/md0 --remove /dev/sdb
> 
> At this point mdadm -E /dev/sda shows that sdb has been removed, but
> mdadm -E of /dev/sdb shows both disks are active and in sync still.  The
> metadata of sdb should be updated when failed or removed if possible.
> 
> mdadm --incremental /dev/sdb
> 
> 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.

> 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
B) did the test in such a way that the raid stack knows the drive is
actually still in sync, in which case it was readded without resyncing
or with only the resyncing necessary to satisfy the bitmap, either of
which was probably so fast you didn't notice it.  To test this to your
satisfaction and make sure that the raid stack is doing what you want,
fail then remove a drive, then do a bunch of writes to the array, *then*
readd the drive using incremental.  It will either get kicked out as
stale, or it will get resynced.  Can't remember which off the top of my
head.

-- 
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 --]