On Mon, Apr 27, 2015 at 07:52:40PM -0500, Eric Sandeen wrote:
> 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.
We already have a field for that - it's called the filesystem
label and the entire userspace infrastructure is already aware of
# blkid /dev/md0 /dev/sda1
/dev/md0: LABEL="root" UUID="91e3089c-f00f-4c56-ab5a-ea8f18b6c011" TYPE="xfs"
/dev/sda1: LABEL="boot" UUID="509d4612-3bbc-4876-a6ac-1d5454ea074d" TYPE="ext2"
# $ ls -l /dev/disk/by-label
lrwxrwxrwx 1 root root 10 Mar 16 09:01 boot -> ../../sda1
lrwxrwxrwx 1 root root 9 Mar 16 09:01 root -> ../../md0
# man 5 fstab
Instead of giving the device explicitly, one may indicate
the (ext2 or xfs) filesystem that is to be mounted by its UUID
or volume label (cf. e2label(8) or xfs_admin(8)), writing
LABEL=<label> or UUID=<uuid>, e.g., `LABEL=Boot' or
> > 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.
I think that labels are a far better way of dealing with this
problem. Get rid of the UUID mount checking (and hence the nouuid
mount option), and tell people to use by-label instead of by-uuid to
identify their filesystems when doing clones and snapshots. Labels
make it much easier for humans to identify the filesystem than