Chris Murphy posted on Fri, 28 Nov 2014 00:10:40 -0700 as excerpted: > On Thu, Nov 27, 2014 at 2:08 AM, Duncan <1i5t5.dun...@cox.net> wrote: >> So, umm... kinda late now, but read that "copy" as if it had a footnote >> attached, saying "Yes, I know it's not actual copy, it's two views of >> the same thing using COW, but my point is, from the btrfs perspective >> it's a copy, the "universally UNIQUE ID" no longer looks "unique" and >> thus no longer can be properly called a UUID at all." > > The copy is sort of a misnomer anyway because up until the computer age > the copy was a derivative, a facsimile, like a photocopy. But a copy of > a digital file is actually another original. Therein lies the problem > with the LVM snapshot in this context, we don't want another original. > We want a copy, as in we want something we know has been derived from > something else, and therefore can be discriminated.
Very good point. I had all the pieces but hadn't put them together yet, so thanks. =:^) > Well RFC 4122 I don't think would say it's not a UUID, the uniqueness is > only guaranteed at the time of UUID creation. And duplication isn't > creation so it's not going to say these things are no longer UUIDs, > they're just UUIDs that have been recycled. That RFC doesn't specify > workflow, but if it did, I think it'd basically say "oh crap, why'd you > go and do that?" After all a major point of UUIDs is that they are > effectively unlimited in quantity, therefore a.) we don't need central > registry to avoid (unintended) collisions because they're so uncommon, > b.) we're encouraged to not be attached to specific UUIDs when in doubt > just create another one. Another good point. One common and less RFC/technical way of putting it, that I had thought about a few times but hadn't actually posted yet IIRC, is the old "If it hurts when you bang your head against the wall, quit banging!" =:^) IOW, LVM could change the UUIDs in its "copies", COWing that bit in ordered to do so. While that wouldn't change the same UUIDs embedded in for instance btrfs internals it would provide a mechanism to keep initial scans from confusing things, and filesystems or other UUID applications that duplicated the number for their own internals would then need to provide tools that rewrote them to match the LVM-changed master location UUID. Those that failed to do so would fail to function unless/until the master location version was changed back, but the tools and likely would eventually be provided, as I expect they will be here, but the difference would be at least it'd keep mixups like this from happening. > A very good example of WTF reusage of a UUID that irks me to no end is > GNU parted devs decided to recycle the Microsoft Windows Basic Data > partition type GUID for Linux partitions. It's like watching someone get > run over by a zamboni with 50 feet of advance notice... At least I don't have to worry about that one, since I no longer agree to "WE REFUSE TO TELL YOU SPECIFICALLY WHAT THIS SOFTWARE DOES AS WE DON'T SUPPLY THE SOURCES, BUT YOU ARE STILL REQUIRED TO ACCEPT ALL RESPONSIBILITY FOR IT, REGARDLESS OF WHAT IT DOES AND REGARDLESS OF WHETHER WE'VE BEEN WARNED" style EULAs, which is basically all of them, which means I have no legal way to run that software, so I don't. Note that the GPL among others has similar liability disclaimer wording (and to be fair it'd be hard not to, since the sources are there and the original author can hardly be held responsible for later modifications to them), but because it actually gives you the sources too, it allows you to fairly make your own decision about the responsibility you're about to take on. Since I can't/won't run pretty much anything proprietary, there's little chance of it being taken as anything but Linux, here. (Tho I actually use (c)gdisk for partitioning here and it appears to use a different GUID. (0700 in its short form which AFAIK is gdisk specific, for MS basic data, while it uses 8300 for general Linux filesystems. I could look up the long form GUIDs, but meh...) -- 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
