On Sat, 2015-12-05 at 12:01 +0000, Hugo Mills wrote: > On Sat, Dec 05, 2015 at 04:28:24AM +0100, Christoph Anton Mitterer > wrote: > > On Fri, 2015-12-04 at 13:07 +0000, Hugo Mills wrote: > > > I don't think it'll cause problems. > > Is there any guaranteed behaviour when btrfs encounters two > > filesystems > > (i.e. not talking about the subvols now) with the same UUID? > > Nothing guaranteed, but the likelihood is that things will go > badly > wrong, in the sense of corrupt filesystems. Phew... well sorry, but I think that's really something that makes btrfs not productively usable until fixed.
> Except that that's exactly the mechanism that btrfs uses to handle > multi-device filesystems, so you've just broken anything with more > than one device in the FS. Don't other containers (e.g. LVM) do something similar, and yet they don't fail badly in case e.g. multipl PVs with the same UUID appear, AFAIC. And shouldn't there be some kind of device UUID, which differs different parts of the same btrfs (with the same fs UUID) but on different devices?! > If you inspect the devid on each device as well, and refuse > duplicates of those, you've just broken any multipathing > configurations. Well, how many people are actually doing this? A minority. So then it would be simply necessary that multipathing doesn't work out of the box and one need to specifically tell the kernel to consider a device with the same btrfs UUID as not a clone but another path to the same device. In any cases, rare feature like multipathing cannot justify the possibility of data corruption. That situtation as it is now is IMHO completely unacceptable. > Even if you can handle that, if you have two copies of dev1, and > two copies of dev2, how do you guarantee that the "right" pair of > dev1 > and dev2 is selected? (e.g. if you have them as network devices, and > the device enumeration order is unstable on each boot). Not sure what you mean now: The multipathing case? Then, as I've said, such situations would simply require to manually set things up and explicitly tell the kernel that the devices foo and bar are to be used (despite their dup UUID). If you mean what happens when I have e.g. two clones of a 2-device btrfs, as in fsdev1 fsdev2 fsdev1_clone fsdev2_clone Then as I've said before... if one pair of them is already mounted (i.e. when the *_clone appear), than it's likely that these belong actually together and the kernel should continue to use them and ignore any other. If all appear before any is mounted, then either is should refuse to mount/use any of them, or it should require to manually specify which devices to be used (i.e. via /dev/sda or so). Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
