Re: question: no-bitmap RAID1 with off-site drive

Started playing with the third drive
and my invented approach may not
be correct.  That, as recommended,
using --grow to eliminate the offsite
"removed" drive and put back the
rotate-in drive is right.

It looks like MD re-initializes the
superblock (different UUID) when
something like

  mdadm --grow --add --raid-devices=3 /dev/md3 /dev/sde

is run, even if /dev/sde has a previous
superblock from the same array.  However
I only tested it with a drive image that
had not been fully synced and from the
same (not different) array.  Running

   mdadm --re-add /dev/md3 /dev/sde

results 'mdadm' refusing the
drive that had been from the
same array (though not fully synced).

Appears then that 'mdadm' may not
check the superblock to see if the
drive came from a different array
and should not be overwritten, and
instead prefers to just zap it.

Can anyone confirm or deny the
possibility?  I can manually run
an --examine and check the array
name as a precaution when rotating
drives if 'mdadm' doesn't perform
the check.  Want to avoid inserting
a offsite drive in the wrong array.




At 12:26 PM 11/12/2012 -0500, starlight.2012q4@binnacle.cx wrote:

After some pondering, think I've figure it out.

Best way to go is to set it up with

 --create --level=1 --raid-devices=2

for the initial pair of drives, then

 --fail --remove

the rotate-out drive, then

 --add

the alternate drive.  Now there will be
three drive slots with one "removed" and two
"active".

To rotate a drive off-site

  --fail --remove

go to the off-site, swap the drives and on return

  --re-add

the rotate-in drive.

This way the 'mdadm' UUID labels will stay on the
drives and 'mdadm' will warn against mistakes
such as trying to use the wrong drive for
a mirror pair.  Will always have one "removed"
drive.

The

  --grow --raid-devices=1 --force

and

  --grow --raid-devices=2 --add

would be used only if a drive fails and needs to
be replaced.

If anyone disagrees please advise.