Btrfs subvolume UUID clash

Question

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)

Answer 1

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/[email protected]/msg49133.html (was http://thread.gmane.org/gmane.comp.file-systems.btrfs/50909/focus=50917)

Now I can sleep better :p

Answer 2

I don't know the direct answer to your question, but here's a generic way to find out.

This is one of the things that VMs are for, experimenting and testing and investigating software behaviour that you aren't sure about.

1. Create a new VM. Give it a boot disk, and 2 or 4 virtual disks for btrfs testing. Size isn't really important.
2. Install a linux distro on the boot disk and start it up
3. Using 1 or 2 of the extra virtual disks, create a btrfs filesystem. Put some data on it. create some subvolumes. Put some data in them.
4. Unmount it and clone it to the other 1 or 2 virtual disks.
5. Change the UUID on the clone with btrfstune -u
6. Mount both btrfs filesystems at the same time.

7. Read and write to both brtfs filesystems (maybe run bonnie++ or similar simultaneously on both filesystems), and make note of any unusual or unwanted behaviour. Especially check for corruption when you write to duplicate subvolumes of either btrfs filesystem.

8. Post an answer here so that others benefit from your research.