On Ubuntu 18.04 I create a RAID 1 array like this:
mdadm --create /dev/md/myarray --level=1 --run --raid-devices=2 /dev/sdc /dev/sdd
I then add the output of mdadm --detail --scan /dev/md/myarray
to /etc/mdadm/mdadm.conf. It looks like this:
ARRAY /dev/md/myarray metadata=1.2 name=MYHOSTNAME:myarray UUID=...
The device name has been prefix with "MYHOSTNAME:". At this point the symlink /dev/md/myarray
still exists, but after the first time I reboot it becomes /dev/md/MYHOSTNAME:myarray
, breaking things. To make it worse, this happens only on some machines – on others the symlink remains /dev/md/myarray
. All are running Ubuntu 18.04, so I have no idea why.
How do I get a consistent device path for my MD device, ideally the exact one I specified ("/dev/md/myarray")? I tried editing mdadm.conf to remove the hostname, but even if the line says
ARRAY /dev/md/myarray metadata=1.2 name=myarray UUID=...
the symlink still changes on reboot – on machines that "want" the hostname. I also tried going the other way and adding the hostname in both place:
ARRAY /dev/md/HOSTNAME:myarray metadata=1.2 name=HOSTNAME:myarray UUID=...
but again on machines that "don't want" the hostname the symlink becomes /dev/md/myarray after a reboot!
I can't use the numeric device (/dev/md127) either because when there are multiple MD devices created like this they tend to alternate between md126 and md127 as well! This is crazy!
Best Answer
After
mdadm --create /dev/md/foobar ...
, bothhostname
andname
are stored in the mdadm metadata, as you should verify withmdadm --examine
ormdadm --detail
:ALU
happens to be the hostname of my ArchLinux machine:You can specify the host that should be stored at create time:
...but usually nobody remembers to do that.
And that's already where the problems start... you might have created your RAID array from some LiveCD or other, and the hostname in that environment didn't match your main install at all. And then the metadata stores some completely unrelated hostname.
Similarly if you set everything up correctly, but then encounter problems with your RAID and boot a rescue system to check things out, yet again there's a mismatch with the hostnames.
Or the other way around, the hostname may match even if it's the wrong machine - if you used the same hostname for two independent systems and then migrate drives. Then the alien arrays take over the names of the original ones...
Now, the metadata can also be changed later using
mdadm --assemble --update=homehost
or--update=name
, that is one way to deal with problem. It should be set correctly but it's difficult to change as (for some reason) short of hexediting metadata directly, it can only be done at assembly time.Another way is to ignore the systems
hostname
and instead specify--homehost
on assembly or setHOMEHOST
inmdadm.conf
. This is described in some detail in the mdadm.conf manpage.So you can try to set
HOMEHOST ALU
(in my case), or the more genericHOMEHOST <ignore>
(orHOMEHOST <none>
) in themdadm.conf
. But it will only work when thatmdadm.conf
is present. And again if you set ignore and then hook up an array from another machine, you might run into name conflicts.So it'd be best to set the hostname correctly in metadata and mdadm.conf and not ignore it, and better yet set the actual hostname in initramfs before assembly but it can be hard to put into practice.
My personal preference is to just stick to the classic numeric style. Identify by UUID and nothing else:
This is also consistent (but also depends on it to have been created this way and/or set accordingly in the metadata, otherwise you also might have to
--update
it). And alien arrays that don't match the given UUIDs should end up as/dev/md127+
.At the end of the day no matter what you do, you should not blindly rely on
/dev/mdX
or/dev/md/name
s the same way you don't blindly rely on/dev/sdX
letters. Always use filesystem UUIDs to identify whatever is on those arrays.There's too many corner cases where names might unexpectedly change, so at best, this can be an orientation help or hint to the sysadmin, it's not the answer to all problems.