6

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)

2
  • Maybe not data corruption, but it can easily cause problems.See unix.stackexchange.com/questions/104067/… Dec 2, 2015 at 21:56
  • @NaftuliTzviKay Thanks, but I read that already. It's about the main UUID only, and has outdated information (because, as of now, a tool to change it does exist). Or did I miss something?
    – deviantfan
    Dec 2, 2015 at 22:01

2 Answers 2

2

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

4
  • External link is broken.
    – ceremcem
    Jun 10, 2017 at 0:11
  • @ceremcem Yes, and whole gmane seems broken (ie. all other mailing lists and mails too) ... I'll wait a bit, hopefully it goes online again soon.
    – deviantfan
    Jun 10, 2017 at 7:09
  • @deviantfan Still dead :(
    – Tom Hale
    Oct 13, 2017 at 20:29
  • @TomHale Thanks for reminding me of this. I found a post on the blog of GManes creator that he's not planning on running the web interface anymore (he's still doing NNTP apparently), and that he's searching people to take over the web part. ... So, for now, I switch that link to mail-archive
    – deviantfan
    Oct 14, 2017 at 1:36
0

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .