How do filesystem UUID's work from kernelspace perspective (and what can happen to my Linux machine when it is not unique)?

Question

In the end I guess that is really the question I want to find an answer for: Can I crash a Linux box if the root filesystem does not have a unique UUID? But please read on, this question is about understanding the cause in depth and not so much the effect of a faulty configuration.

Given the fact that I can clone an entire root filesystem including its UUID in a separate partition of identical size. On both the original and the clone the inodes would point you to a copy of the same file and the same block on disk (partitionwise), so you wouldn't notice anything starting to go wrong.

But if so, I want to understand why, or what the nature of problems would be that can be expected. There are a lot of writings on the topic how UUID's in filesystems can ease your life, how they are supposed to work, how udev builds nice device trees in /dev. And there is the remark UUID's must be unique in a Linux box. I guess UUID's are well documented from a userspace perspective, but I want to understand the kernelspace perspective better.

Could you for example get some sort of split brain situation where some blocks are read or written from the one partition and other blocks from the other partition? Can the kernel lock up? Perhaps trouble mounting and/or unmounting the other device? Perhaps on a side track: How does multipathing fit in, which is able to manage a very specific case of duplicate UUID's.

Back to the actual question: How does the kernel actually utilize these UUID's internally? When I mount a filesystem by UUID and I inspect the output of mount, df or /proc/mounts, none of these show the UUID that I used to issue the mount command with, they always show me the device node in /dev. Is there a userspace interface for the UUID to device mapping (which is not necessarily the same as device to UUID)? How does the kernel decide which block device to access and can this more or less spontaneously change over time, maybe due to certain events? What can happen to my machine / filesystems if I do not obey the simple rule of unique UUID's?

Perhaps my answer is in https://www.kernel.org/doc/ but that is a bit overwhelming when I don't known what exactly I am searching for. Deep links into this website are welcome too.

Answer 1

It's quite simple really.

You may have partitions with non-unique UUIDs no problem, but when you actually mount them, the kernel creates a link between the unique device node in /dev to the specified mount point which means at no point reads and writes could go to different devices.

And if you find yourself in a situation like this when e.g. you clone an unmounted partition and then try to mount it using UUID, the mount utility will mount either of partitions randomly but you can always consult with the mount output to check which device has actually been used.

How does the kernel actually utilize these UUID's internally?

It does not. The kernel uses device nodes.

Is there a userspace interface for the UUID to device mapping (which is not necessarily the same as device to UUID)?

Check ls -la /dev/disk/by-uuid.

How does the kernel decide which block device to access and can this more or less spontaneously change over time, maybe due to certain events?

When you have non-unique partitions I can imagine the kernel could use any of them at any given time but only once (you attempt to mount them).

What can happen to my machine / filesystems if I do not obey the simple rule of unique UUID's?

It will not blow up but I wouldn't recommend keeping this configuration. Clone partitions and remove the destination disk.