1

I'm trying to setup a RAID6 on my Ubuntu machine with mdadm.

I read a few tutorials and all of them use partition names directly like:

$ sudo mdadm \
       --create /dev/md0 \
       --level=6 --raid-devices=4 \
       /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1

As far as I know partition names can change depending on where they're connected to.

So (logically) I tried to "bind" the partitions not by name but by UUID and surprisingly I didn't find much resources when it comes to doing that.

I've found one post here that I think tries the same.

The methodology in the post uses /dev/disk/by-partuuid/<X> where <X> is some ID presumably obtained through a command like sudo blkid /dev/sdX.

My question is now, how would I go about creating a RAID6 array with UUIDs instead of partition names?

Also, as a bonus: I've read that omitting devices in /etc/mdadm/mdadm.conf leads mdadm to "scan" the partitions for superblocks and assemble the array based on that. Is that a good methodology for a local RAID setup?

Marcus Müller
  • 21,602
  • 2
  • 39
  • 54
Marco
  • 124
  • 2
  • 13
  • but you already answered your question in your post: you use `/dev/disk/by-partuuid/*` instead of `/dev/sdd1` (or whatever specific device node). So, what's the question? – Marcus Müller Feb 28 '23 at 18:49
  • @MarcusMüller have I? Do you actually use `/dev/disk/by-partuuid/X` instead of `/dev/sbX`? – Marco Feb 28 '23 at 19:07
  • you use `/dev/disk/by-partuuid/1ed967a0-78ec-4e3e-b5df-4e6994fdabcd`. I recommend running `ls -lh /dev/disk/by-partuuid`. – Marcus Müller Feb 28 '23 at 19:08
  • What I'm asking (I suppose) is _"what is the canonical way to make a RAID with UUIDs instead of partition names"_ since I didn't find any resources covering the topic. – Marco Feb 28 '23 at 19:10

1 Answers1

1

It's a hen-and-egg problem.

Using UUIDs is not wrong, but in order to use them, they have to exist first.

Block devices get their UUIDs from metadata that is on them. mdadm --create is one of the commands that write such metadata to a block device. Without running mdadm --create first, there is no UUID. So you can only specify the device names directly as /dev/sd{a,b,c,d}1.

Otherwise, you have to rely on some other UUID provider. The PARTUUID is provided by the partition table. You can use it. It will work.

If there is no partition table yet, there is no PARTUUID. In that case udev also provides a ton of other device names under /dev/disk/*/*, for example you might find the device model and serial number in there. So it's possible to use unique device names even before any UUIDs are created at all.

It's usually not done since you'd use other commands to ascertain the identity of those block devices, before running parted, mdadm --create, mkfs etc. on them.

It's fine to specify /dev/sd{a,b,c,d}1 if you've checked that these are the correct devices at the time you run your command. Afterwards, in mdadm.conf, fstab etc. you use UUIDs exclusively unless you have strong reasons not to.

frostschutz
  • 47,228
  • 5
  • 112
  • 159
  • The end of the post I linked suggested leaving the `devices` out completely since (apparently) mdadm is able to scan superblocks on devices and is able to re-assemble the array on its own. I know, this assumes that you have already created an array (which would be the case in my question). I just want to make sure to configure raid once so that I don't have to worry about it later (e.g. when adding hard drives to my array, changing out disks etc.) – Marco Feb 28 '23 at 19:16
  • 1
    @Marco yeah you don't put device names in mdadm.conf ... this happens because people just redirect mdadm --scan --verbose output to mdadm.conf but it's too verbose and also half of the things listed in there can change anytime (drives can be replaced. raid levels can be changed. arrays can be grown. etc.). Only the UUID remains the same (unless you go out of your way to change that, too) so the UUID is all you need in the mdadm.conf to make your ARRAY lines work. – frostschutz Feb 28 '23 at 19:22
  • Thanks. This is what I'm going for, more configuration means more things that could break in the future. Thank you for your answer I'll mark it as accepted. – Marco Feb 28 '23 at 22:08