On Mon, Dec 14, 2015 at 6:23 AM, Austin S. Hemmelgarn <ahferro...@gmail.com> wrote: > > Agreed, if yo9u can't substantiate _why_ it's bad practice, then you aren't > making a valid argument. The fact that there is software that doesn't > handle it well would say to me based on established practice that that > software is what's broken, not common practice.
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. 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. I've already said data recovery (including forensics) and sticking drives away on a shelf could be reasonable. > The assumption that a UUID is actually unique is an inherently flawed one, > because it depends both on the method of generation guaranteeing it's unique > (and none of the defined methods guarantee that), and a distinct absence of > malicious intent. http://www.ietf.org/rfc/rfc4122.txt "A UUID is 128 bits long, and can guarantee uniqueness across space and time." Also see security considerations in section 6. > On that note, why exactly is it better to make the filesystem UUID such an > integral part of the filesystem? The other thing I'm reading out of this > all, is that by writing a total of 64 bytes to a specific location in a > single disk in a multi-device BTRFS filesystem, you can make the whole > filesystem fall apart, which is absolutely absurd. OK maybe I'm missing something. 1. UUID is 128 bits. So where are you getting the additional 48 bytes from? 2. The volume UUID is in every superblock, which for all practical purposes means at least two instances of that UUID per device. Are you saying the file system falls apart when changing just one of those volume UUIDs in one superblock? And how does it fall apart? I'd say all volume UUID instances (each superblock, on every device) should be checked and if any of them mismatch then fail to mount. There could be some leveraging of the device WWN, or absent that its serial number, propogated into all of the volume's devices (cross referencing each other's devid to WWN or serial). And then that way there's a way to differentiate. In the dd case, there would be mismatching real device WWN/serial number and the one written in metadata on all drives, including the copy. This doesn't say what policy should happen next, just that at least it's known there's a mismatch. -- Chris Murphy -- 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
