On 4/27/15 6:37 PM, Dave Chinner wrote: > On Mon, Apr 27, 2015 at 05:10:25PM -0500, Eric Sandeen wrote: >> Wanted to float this & see what people think... >> >> Today, it's impossible (FSVO impossible) to change a V5 filesystem's >> UUID, because that UUID is stamped into every bit of metadata. If >> not impossible, it's unimplemented and any implementation would be >> terribly inefficient. >> >> With 20/20 hindsight, an sb_meta_uuid field, separate from the sb_uuid >> field that is userspace-visible, would have avoided this problem. > > Actually, it was done like this intentionally. > > AFAIA, the only time you need to change the UUID is if you are doing > clones or snapshots of the filesystem. If you are doing a clone, > then we are reading and writing every piece of metadata anyway, so > we /could/ add support for modifying the UUIDs to the cloning > program during the write. e.g. xfs_copy already does this UUID > modification for non-crc filesystems, so we could modify it to reuse > the db/metadump metadata walk to rewrite the UUIDs and recalculate > the CRCs once the copy has been done. That's the clone problem > solved. Fair enough. > If we have a snapshot, then changing the UUID means a COW of every > single metadata block as we change them, which will cause all sorts > of fragmentation and duplication problems in the underlying snapshot > device due to the random 4k distribution of the metadata throughout > the filesystem. So we take even more of a penalty there, as it also > affects runtime performance and space usage of the underlying > device. Hence I'm not sure we actually want to change behaviour > here. This I'm not following. Changing UUID by rewriting every piece would be painful in this case, yes. I guess we're in violent agreement on this part? (that changing the UUID of a RW snapshot would be nuts). >> We can certainly add it, but it'd need to be an incompat change, because >> old kernels would see this as catastrophic mismatching of every bit >> of metadata on a V5 superblock filesystem. >> >> Other than that little problem (o_O) it'd be trivial to implement. > > So what you are proposing is a fixed UUID for metadata, and a > variable UUID for userspace presentation (i.e. blkid) and mount > checking? Doesn't that defeat the purpose of the UUID which is to > identify the filesystem the metadata originated from? i.e. don't we > still need to change the internal metadata UUID if we want to retain > the original purpose of the UUID stamping in the metadata? No, I don't think so. sb_uuid could be changed just like it always ever could, for any reason one might wish to change it; it'd be relatively trivial. sb_meta_uuid would be set at mkfs time, and would never change; it's the matching, immutable metadata consistency number. sb_uuid is for external filesystem identification; sb_meta_uuid is for internal consistency. If we got a metadata uuid mismatch from xfs_repair, xfs_db (or xfs_admin) could easily tell us what the sb_meta_uuid of any given filesystem might be, and we wouldn't care about the external identifier UUID for this purpose. >> Thoughts? > > Can you describe the motivation for needing to change UUIDs? i.e. > what's the use case that has brought this up? I'd like to know if > there is a problem other than writable snapshots being required to > be mounted "-o nouuid", which we already require for read-only > snapshots (i.e "-o ro,norecovery,nouuid")? Well, it's just the loss of ability to change UUID, which is something People Used To Do(tm), and now can't. It does come up. Honestly if it had been done from day 0, it'd be a no-brainer I think. Doing it now, with an incompat flag, might not be a reasonable tradeoff. -Eric _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
