MegaBrutal posted on Sun, 16 Nov 2014 22:35:26 +0100 as excerpted: > Hello guys, > > I think you'll like this... > https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1391429
UUID is an initialism for "Universally Unique IDentifier".[1] If the UUID isn't unique, by definition, then, it can't be a UUID, and that's a bug in whatever is making the non-unique would-be UUID that isn't unique and thus cannot be a universally unique ID. In this case that would appear to be LVM. Meanwhile, if two or more devices are btrfs and have the same UUID, btrfs considers them part of the same filesystem, since btrfs /can/ be a multi- device filesystem. That's not a bug; that's the way btrfs IDs multiple devices as part of the same filesystem, because a UUID, by definition, can be relied upon to be unique, or it's no longer a UUID. Additionally, the UUID is actually written into the metadata of the filesystem in such a way that it's /not/ a simple task to change the UUID. Put simply, it's "ingrained" into the filesystem so deeply it cannot be changed, at least not without rewriting pretty much all the metadata. (FWIW, a btrfs balance does just that, rewrite the data, metadata, or both. However, I don't believe a balance plugin to change the UUID is yet available. You're simply not supposed to change the UUID once the filesystem is created.) So if LVM snapshots duplicate a UUID, as I believe they do, then there's your bug, because they're breaking the definition of Universally *UNIQUE* ID. That being the case, using them with btrfs is pretty essentially broken, because btrfs depends on UUIDs to be what they say on the label, actually "unique", and UUIDs are deeply enough ingrained into the very fabric of btrfs that it's simply not possible to change that on the btrfs side. Meanwhile, since btrfs *DOES* depend on UUIDs being unique, if there's multiple btrfs that accidentally have the same UUID, btrfs will not distinguish between them and will very possibly be writing into both of them. If I found myself in that situation, I'd very carefully copy all the data I wanted to save off the filesystem and do a new mkfs as soon as possible, because I would not consider the filesystem as it was at all stable, and I'd count myself very lucky if I got everything off the filesystem without damage. In actuality, since the second device was a snapshot of the first, if you catch it reasonably quickly you likely won't have too many issues. However, a btrfs in that condition is in an undefined state, and the longer it exists in that state, the more likely things are to go wrong, possibly VERY VERY wrong. So if you don't already have backups for anything you consider valuable on that thing, get it off there as soon as you possibly can, and consider yourself very lucky if nothing's damaged as a result. --- [1] http://en.wiktionary.org/wiki/UUID -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
