Re: uuid ioctl - was: Re: [PATCH] overlayfs: Trigger file re-evaluation by IMA / EVM after writes

[Dave Chinner <david@fromorbit.com>]

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@fromorbit.com