On Thu, Mar 16, 2023 at 08:41:14PM +0000, Catherine Hoang wrote: > > On Mar 13, 2023, at 11:28 PM, Dave Chinner <david@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx
