I had copied a RAID filesystem onto larger disks using a second computer and wanted to mount it on the original computer with minimal disruption. To this objective, I made the UUID of the new RAID array the same as the previous RAID using the assemble command of mdadm, like this:
mdadm -A /dev/md1 -U uuid --uuid=<old RAID UUID> /dev/sdb3 /dev/sdc3
(If the array is currently assembled, you have to disassemble it it first with mdadm -S /dev/md1)
This worked fine and I was able assemble the RAID on the second computer using the /etc/mdadm.conf from the first computer.
At the same time I decided to change to mount by UUID, so I edited /etc/fstab to look like this:
/dev/disk/by-uuid/<RAID UUID> /home xfs default 1 2
Alas when I booted, the RAID array wouldn't mount and I had to reboot in rescue mode to fix it up.
I wondered why the discrepancy between the symlink to /dev/md1 in /dev/disk/by-uuid and the RAID UUID. Eventually after some red herrings I understood. RAID UUID != filesystem UUID. They are distinct UUIDs. The filesystem UUID is that of the XFS (or ext4, btrfs, whatever) filesystem on it and is what is reported by blkid when udev runs it to populate the by-uuid directory. On the other hand the RAID UUID is what mdadm uses to match against entries in /etc/mdadm.conf when assembling the array.
The second lesson I learnt (again) is that you should not change two things in your config at once. I should have booted the machine up with /dev/md1 in /etc/fstab and then explored by-uuid later.
I could have kept the random RAID UUIDs generated by mdadm for the new disks and just run mdadm --examine --rescan > /etc/mdadm.conf in rescue mode to rebuild the metadata, but I want to be able to swap in the old RAID disk in an emergency and it's one less step to make the RAID UUIDs the same.
mdadm -A /dev/md1 -U uuid --uuid=<old RAID UUID> /dev/sdb3 /dev/sdc3
(If the array is currently assembled, you have to disassemble it it first with mdadm -S /dev/md1)
This worked fine and I was able assemble the RAID on the second computer using the /etc/mdadm.conf from the first computer.
At the same time I decided to change to mount by UUID, so I edited /etc/fstab to look like this:
/dev/disk/by-uuid/<RAID UUID> /home xfs default 1 2
Alas when I booted, the RAID array wouldn't mount and I had to reboot in rescue mode to fix it up.
I wondered why the discrepancy between the symlink to /dev/md1 in /dev/disk/by-uuid and the RAID UUID. Eventually after some red herrings I understood. RAID UUID != filesystem UUID. They are distinct UUIDs. The filesystem UUID is that of the XFS (or ext4, btrfs, whatever) filesystem on it and is what is reported by blkid when udev runs it to populate the by-uuid directory. On the other hand the RAID UUID is what mdadm uses to match against entries in /etc/mdadm.conf when assembling the array.
The second lesson I learnt (again) is that you should not change two things in your config at once. I should have booted the machine up with /dev/md1 in /etc/fstab and then explored by-uuid later.
I could have kept the random RAID UUIDs generated by mdadm for the new disks and just run mdadm --examine --rescan > /etc/mdadm.conf in rescue mode to rebuild the metadata, but I want to be able to swap in the old RAID disk in an emergency and it's one less step to make the RAID UUIDs the same.
No comments:
Post a Comment