How to update homehost of an existing raid component

Hi,

Please is there a way to update a homehost value for a specific raid component?

md7 is raid1 composed of md5 and md6. UUID of md7 is listed in mdadm.conf:

ARRAY /dev/md7 level=raid1 num-devices=2 metadata=01.00 UUID=dde16cd5:2e17c743:fcc7926c:fcf5081e

Every time I reboot, md7 is auto assembled only from md5. When running manually, I get

mdadm --verbose -A /dev/md7 --scan
...
mdadm: /dev/md6 misses out due to wrong homehost
...

Indeed, all the raid components (there are many more belonging to different raids on my machine) list the "local to host orfeus" homehost, such as:

orfeus:~# mdadm --examine /dev/md5
/dev/md5:
          Magic : a92b4efc
        Version : 1.0
    Feature Map : 0x0
     Array UUID : dde16cd5:2e17c743:fcc7926c:fcf5081e
           Name : orfeus:7  (local to host orfeus)
  Creation Time : Wed Jan 19 21:36:19 2011
     Raid Level : raid1
   Raid Devices : 2

Avail Dev Size : 4356361184 (2077.27 GiB 2230.46 GB)

     Array Size : 4356361184 (2077.27 GiB 2230.46 GB)
   Super Offset : 4356361440 sectors
          State : clean
    Device UUID : a4973bb6:2cd83805:ba441193:56321f9b

    Update Time : Mon Mar 19 02:36:33 2012
       Checksum : 7b8eeffd - correct
         Events : 11853346

Device Role : Active device 1
Array State : AA ('A' == active, '.' == missing)

While the md6 has the homehost different:

orfeus:~# mdadm --examine /dev/md6
/dev/md6:
          Magic : a92b4efc
        Version : 1.0
    Feature Map : 0x0
     Array UUID : dde16cd5:2e17c743:fcc7926c:fcf5081e
           Name : 'orfeus':7
  Creation Time : Thu Jun 17 22:51:47 2010
     Raid Level : raid1
   Raid Devices : 2

Avail Dev Size : 4356361184 (2077.27 GiB 2230.46 GB)

     Array Size : 4356361184 (2077.27 GiB 2230.46 GB)
   Super Offset : 4356361440 sectors
          State : clean
    Device UUID : 9144c9ad:8ee3ed37:69b53956:03bebdd6

    Update Time : Mon Mar 19 02:36:33 2012
       Checksum : 94c11ff3 - correct
         Events : 11853346

Device Role : Active device 0
Array State : AA ('A' == active, '.' == missing)

There is no "local to host orfeus" in homehost of md6. Otherwise, the array UUID fits that of md7. It was added after last reboot when the array failed to assemble automatically.

Following the man page, I tried running

mdadm --verbose -A /dev/md7 --update=homehost --scan

with no difference. Unfortunately I was not able to find how to change the homehost of md6 to be local to orfeus. I do not want to force adding md6 to the array and go through the whole rebuild since the data themselves are OK.

Thanks a lot for any hints and help.

Best regards,

Pavel.

I don't think you need to.

[...]

I don't think --assemble --scan will include /dev/md6 if the homehost doesn't match :-(

Try mdadm --verbose --assemble /dev/md7 --update=homehost /dev/md5 /dev/md6

And if that doesn't do the business, specify --homehost=orfeus

Cheers,

John.

Dne 19.3.2012 17:46, John Robinson napsal(a):

Hi John,

Thanks a lot for your answer. Unfortunately both commands keep returning the same result:

orfeus:~# mdadm --verbose --assemble /dev/md7 --update=homehost /dev/md5
/dev/md6
mdadm: looking for devices for /dev/md7
mdadm: /dev/md6 misses out due to wrong homehost
mdadm: /dev/md5 is identified as a member of /dev/md7, slot 1.
mdadm: no uptodate device for slot 0 of /dev/md7
mdadm: added /dev/md5 to /dev/md7 as 1
mdadm: /dev/md7 assembled from 1 drive - need all 2 to start it (use
--run to insist).

orfeus:~# mdadm --verbose --assemble /dev/md7 --update=homehost
--homehost=orfeus /dev/md5 /dev/md6
mdadm: looking for devices for /dev/md7
mdadm: /dev/md6 misses out due to wrong homehost
mdadm: /dev/md5 is identified as a member of /dev/md7, slot 1.
mdadm: no uptodate device for slot 0 of /dev/md7
mdadm: added /dev/md5 to /dev/md7 as 1
mdadm: /dev/md7 assembled from 1 drive - need all 2 to start it (use
--run to insist).

orfeus:~# mdadm --version
mdadm - v3.1.4 - 31st August 2010

orfeus:~# uname -a
Linux orfeus 2.6.26-bpo.1-amd64 #1 SMP Sat Sep 20 10:26:59 UTC 2008
x86_64 GNU/Linux

Since I need the server working (it is a company central backup server), I forced starting md7 in degraded mode by including the --run parameter and re-added md6 afterwards. Since both components carry the write-intent bitmap and the degraded array was not accessed in the meantime, md6 was re-added without any synchronization.

Still, md6 is not local to orfeus:

orfeus:~# mdadm --examine /dev/md6
/dev/md6:
....
           Name : 'orfeus':7
...

While md5 is:

orfeus:~# mdadm --examine /dev/md5
/dev/md5:
....
           Name : orfeus:7  (local to host orfeus)
....

Next time the problem will arise again. No idea how to force md6 to become local. It looks as if md6 was created in some preliminary stage of homehost support and its current homehost format is not supported by the mdadm utils. Just my guess though.

John, once more thank you for your invaluable help.

Regards,

Pavel.

There is something very strange here.
md5 and md6 look to some extent like different parts of the same RAID1. They have the same Array UUID, the same "Update Time" and the same "Events" counter.
However they have different "Creation Time" (19/Jan/2011 vs 17/Jun/2010) and different names ("orfeus:7" vs "'orpheus':7").

I cannot imagine how that would happen.

mdadm notices they are different so it cannot use them both. It chooses md5 over md6 as md5 has the 'correct' homehost name.

Your best bet would be to re-create the array so it gets good clean metadata.

mdadm -S /dev/md7
mdadm -C /dev/md7 -l1 -n2 --assume-clean --metadata=1.0 /dev/md6 /dev/md5

should do it. If you want to keep the same uuid, add
--uuid=dde16cd5:2e17c743:fcc7926c:fcf5081e

to that command.

--update=homehost only works when assembling, and updates the homehost for all members of the array. The would work if the create times were the same, but a they are different, mdadm thinks they are different arrays.

NeilBrown

Dne 19.3.2012 22:28, NeilBrown napsal(a):

Neil, thanks a lot for your help. The command worked fine, now both md5 and md6 have the same name.

Regards,

Pavel.