On Fri, Dec 04, 2015 at 01:05:28PM +0100, S.J wrote: > Hello > > As we know, two file systems with the same UUID (like reported by eg. > "blkid") are problematic, especially if both are mounted at the same time it > leads to data corruption. 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?
I don't think it'll cause problems. 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. > (...well, and maybe someone could explain me what these subvol UUIDs are for > in the first place. Subvolumes already have an unique number, and from user > p.o.v, there isn't anything where the subvol UUIDs can be used at all (?)) The subvol UUIDs are used to identify them through send/receive operations. There are three main UUID fields on a subvol: the actual UUID (u), the Received_UUID (r) and the Parent_UUID (p), and these are used to identify whether an incremental send could function correctly when received. (I can give you chapter and verse on how they're used if you like, but that's a bit excessive just for answering your question here). Hugo. > Thank you > > PS: Apologies for sending a second mail, somehow my first try didn't contain > any text -- Hugo Mills | Do not meddle in the affairs of system hugo@... carfax.org.uk | administrators, for they are subtle, and quick to http://carfax.org.uk/ | anger. PGP: E2AB1DE4 |
signature.asc
Description: Digital signature
