Re: [PATCH v1 0/4] setting uuid of online filesystems

[Dave Chinner <david@fromorbit.com>]

On Thu, Mar 16, 2023 at 08:41:14PM +0000, Catherine Hoang wrote:
> > On Mar 13, 2023, at 11:28 PM, Dave Chinner <david@fromorbit.com> wrote:
> > 
> > On Mon, Mar 13, 2023 at 09:21:05PM -0700, Catherine Hoang wrote:
> >> Hi all,
> >> 
> >> This series of patches implements a new ioctl to set the uuid of mounted
> >> filesystems. Eventually this will be used by the 'xfs_io fsuuid' command
> >> to allow userspace to update the uuid.
> >> 
> >> Comments and feedback appreciated!
> > 
> > What's the use case for this?
> 
> We want to be able to change the uuid on newly mounted clone vm images
> so that each deployed system has a different uuid. We need to do this the
> first time the system boots, but after the root fs is mounted so that fsuuid
> can run in parallel with other service startup to minimize deployment times.

Why can't you do it offline immediately after the offline clone of
the golden image? I mean, cloning images and setting up their
contents is something the external orchestration software does
and will always have to do, so i don't really understand why UUID
needs to be modified at first mount vs at clone time. Can you
describe why it actually needs to be done after first mount?

> >>  xfs: add XFS_IOC_SETFSUUID ioctl
> >>  xfs: export meta uuid via xfs_fsop_geom
> > 
> > For what purpose does userspace ever need to know the sb_meta_uuid?
> 
> Userspace would need to know the meta uuid if we want to restore
> the original uuid after it has been changed.

I don't understand why you'd want to restore the original UUID given
the use case you've describe. Can you explain the situation where
you want to return a cloned image to the original golden image UUID?

-Dave.
-- 
Dave Chinner
david@fromorbit.com