On Fri, Jun 02, 2023 at 04:34:58PM +1000, Dave Chinner wrote: > IOWs, not only was the ext4 functionality was poorly thought out, it > was *poorly implemented*. Shrug. It's 100% compatible with "tune2fs -U <uuid>" which existed prior to sb->s_uuid and /proc/XXX/mountstats, and which has allowed on-line, mounted changes of the UUID. So as far as I'm concerned, it's "working as intended". It fixed a real bug where racing resize2fs and tune2fs -U in separate systemd unit files could result in superblock checksum failures, and it fixed the that issue. It doesn't make any changes to how on-line "tune2fs -U <uuid>" functioned, because the definition of s_uuid wasn't terribly well defined (and "tune2fs -U" predates it in any case). Originally s_uuid was just to allow /proc/XXX/mountstats expose the UUID, but at this point, I don't anyone has a complete understanding of other assumptions of how overlayfs, IMA, and other userspace utilities have in terms of the assumption of how file system UUID should be used and what it denotes. > However, we have a golden image that every client image is cloned > from. Say we set a special feature bit in that golden image that > means "need UUID regeneration". Then on the first mount of the > cloned image after provisioning, the filesystem sees the bit and > automatically regenerates the UUID with needing any help from > userspace at all. > Problem solved, yes? We don't need userspace to change the uuid on > first boot of the newly provisioned VM - the filesystem just makes > it happen. I agree that's a good design --- and ten years now, from all of the users using old versions of RHEL have finally migrated off to a version of some enterprise linux that supports this new feature, the cloud agents which are using "tune2fs -U <uuid>" or "xfs_admin -U <uuid>" can stop relying on it and switching to this new scheme. What we could do is to make it easy to determine whether the kernel supports the "UUID regeneration" feature, and whether the file system had its UUID regnerated (because some cloud images generated using an older distro's installer won't request the UUID renegeration), so that cloud agents (which are typically installed as a daemon that starts out of an init.d or systemd unit file) will know whether or not they need to fallback to the userspace UUID regeneration. For cloud agents which are installed as a one-shop executable run out of the initramfs, we might be able to change the UUID before the root file system is mounted. Of course, there are those userspace setups where the use of an initramfs is optional or not used at all. So for the short-term, we're going to be stuck with userspace mediated UUID changes, and if there are going to be userspace or kernel subsystems that are going to be surprised when UUID changes out from under them. So having some kind of documentation which describes how various subsystems are using the file system UUID, and whether they are getting it from sb->s_uuid, /proc/XXX/mountstats, or some other source, that would probably be useful. After all, system administrators' access to "tune2fs -U" and "xfs_admin -U" isn't going away, and if we're saying "it's up to them to understand the implications", it's nice if we document the gotchas. :-) - Ted
