Linux – Btrfs subvolume UUID clash

btrfslinuxuuid

Two file systems with the same UUID on the same computer are problematic, eg. it could lead to data corruption, especially if both are mounted at the same time (like the BTRFS wiki says too). So, copying a BTRFS partition with eg. dd to another and use it immediately is bad.

To prevent this,
btrfstune -u /dev/sdaX
changes the UUID of the given partition.

However, BTRFS subvolumes have their own UUID, which can be viewed eg. with
btrfs sub list -u /mountpoint.
This UUIDs are not changed by the command above, and apparently there is no other way to do this.

My question is: Is this a problem similar to the main UUID? Can mounting two BTRFS partitions with equal subvolume UUIDs (but different main UUID) can cause data corruption?

Maybe my confusion comes from the fact I don't understand what they are for. The file system UUID has to be unqiue to identify it and can be used for several things like mounting etc., but subvolumes have already another unqiue number and name (unique within the file system), and there is nothing (?) where the subvolume UUID can be used at all from user POV, except viewing it.

In the meantime, I made some tests. Multiple partitions with some subvolumes and files, partially same name on all partitions, partially different. Querying/creating/removing/moving/reading/modifying subvolumes/files in pretty much any sane combination. Different main UUID, same subvolume UUIDs.
Result: Couldn't see a problem … nonetheless some assurance that it won't corrupt data even in unusual situations, because xyz, would be nice 🙂

For sake of completeness, same main UUID leads, as expected, to data corruption, and it does this immediately, not just in unusual situations. The kernel (or something) confuses which partition should be accessed for each and any access. Most times it goes either to the first or last partition (in the chronological mounting order), independent of which mount point was used. … There were no "garbage data" corruptions, at least in my tests, but what happened is bad enough, especially if partition one was already in use while partition 2 got mounted (in some sense, then it is indeed garbage)

Best Answer

tldr: It's ok, no possible data corruption.

Asked at the mailing list too, and they explained that the subvol UUID
is just used a sanity check for btrfs send and btrfs receive.

...
The UUIDs on subvols are only really used internally to that filesystem, so the kernel doesn't have a chance to get confused. The main thing that could be confused is send/receive, but that's a matter of possibly losing some validation (thus allowing you to do something that will fail) rather than causing active damage, as in the duplicate-FS-UUID case.
...

from https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg49133.html (was http://thread.gmane.org/gmane.comp.file-systems.btrfs/50909/focus=50917)

Now I can sleep better :p

Related Question