4

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)

  • Maybe not data corruption, but it can easily cause problems.See unix.stackexchange.com/questions/104067/… – Naftuli Kay Dec 2 '15 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 '15 at 22:01
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/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

  • External link is broken. – ceremcem Jun 10 '17 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 '17 at 7:09
  • @deviantfan Still dead :( – Tom Hale Oct 13 '17 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 '17 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.