On Mon, 2015-12-14 at 14:26 -0700, Chris Murphy wrote: > The automobile is invented and due to the ensuing chaos, common > practice of doing whatever the F you wanted came to an end in favor > of > rules of the road and traffic lights. I'm sure some people went > ballistic, but for the most part things were much better without the > brokenness or prior common practice. Okay than take your road traffic example, apply it to filesystems.
In road traffic you have rules, e.g. pedestrians may cross the road when their light shows green and that of the cars red. That could be the rule, similar as to "don't have duplicate UUIDs with btrfs". Despite we have the rule, cars stop at red, pedestrians walk at green, we still teach our kids: "look at both sides on the road, only cross if there's no car (or tank or whatever ;) ) crossing. Applying that to filesystems would be: "hope that everyone plays the rules, but don't kill yourself in one doesn't and there are duplicate IDs). > So the fact we're going to have this problem with all file systems > that incorporate the volume UUID into the metadata stream, tells me > that the very rudimentary common practice of using dd needs to go > away, in general practice. Sure, for those that use multiple devices (LVM, MD, etc.), or for those that actually just use the UUID to select the block device for each write/read (and not use these only "once") to get the right major/minor dev id (or whatever the kernel uses internally for path based addressing). > http://www.ietf.org/rfc/rfc4122.txt > "A UUID is 128 bits long, and can guarantee uniqueness across space > and time." But of course not in terms of the problems we're talking about here, where UUIDs may be accidentally or maliciously duplicated. > Also see security considerations in section 6. Doesn't section 6 basically imply that you can not 100% guarantee they're equal? E.g. bad random seed on multiple systems? Also, IIRC, one of the UUID algos just used some combination of MAC, time and PID... which especially in VMs may even lead to dupes. Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
