On Fri, Jun 02, 2023 at 10:58:16AM -0400, Theodore Ts'o wrote: > On Fri, Jun 02, 2023 at 04:34:58PM +1000, Dave Chinner wrote: > > 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. We're talking about building new infrastructure - regardless of anything else in this discussion, existing software will always do what existing software does. As low level infrastructure designers, we have to think *10 years ahead* and design for when the feature will be widespread. Designing infrastructure with "we need a fix right now" in mind almost always ends with poor results because the focus is "this thing right now" instead of "how will this work when this gets deployed world-wide by everyone".... ext4 developers and the hyperscalers that employ them made a bad decision due to short-termism. It's only right that the wider community pushes back against propagating that bad decision into generic code that everyone will have to live with for the next 20+ years. We can do better. We *should* be doing better. > 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 No, "we" aren't stuck with whacky dynamic runtime ext4 UUID changes. *ext4 developers* and _hyperscalers that have deployed this on ext4_ are stuck with this awful stuff. Everyone else gets to learn from the mistakes that have been made, and "we" will end up with a generic solution that is better and will work on all filesystems that support UUIDs, including ext4. -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
