[PATCH RFC 0/3] fs: online filesystem uuid operations

From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: darrick.wong@oracle.com
Cc: linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-ext4@vger.kernel.org
Subject: [PATCH RFC 0/3] fs: online filesystem uuid operations
Date: Thu, 27 Feb 2020 13:33:35 -0800	[thread overview]
Message-ID: <158283921562.904118.13877489081184026686.stgit@magnolia> (raw)

Hi all,

This patch series creates a couple of new ioctls to query and set the
filesystem uuid of mounted filesystems.  This is apparently desirous for
some cloud providers who wish to be able to deploy pre-baked rootfs
images to a machine, boot it, and have the client machine be able to
change the label and uuid to reflect that it's now derivative of the
original image.

For ext4 this is pretty easy to do as all the pieces are already in
place.  For XFS this is a little more difficult because we need to get
our house in order w.r.t. dependencies between the log uuid and
filesystem superblock uuid, which means that this is really new ext4
functionality that I'd like to share with the other filesystems.

I'm particularly curious to hear what people think about the
FORCE_INCOMPAT flag.  There are some circumstances (namely when the
entire fs metadata is keyed to a certain uuid) where we can only change
the uuid by turning on an incompat feature flag.  The currently running
kernel should be able to handle that just fine, but older kernels won't
be able to mount the fs after that.  We (XFS) normally don't do things
like that, which is why I require positive affirmation from userspace
that doing so is ok.

This is an extraordinary way to destroy everything.  Enjoy!
Comments and questions are, as always, welcome.

--D