Re: [PATCH] xfs: use a unique and persistent value for f_fsid

From: Amir Goldstein <amir73il@gmail.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: Dave Chinner <david@fromorbit.com>,
	"Darrick J . Wong" <darrick.wong@oracle.com>,
	Jan Kara <jack@suse.cz>,
	Christian Brauner <christian.brauner@ubuntu.com>,
	linux-xfs <linux-xfs@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Linux API <linux-api@vger.kernel.org>,
	"J. Bruce Fields" <bfields@fieldses.org>
Subject: Re: [PATCH] xfs: use a unique and persistent value for f_fsid
Date: Sat, 27 Mar 2021 12:14:51 +0300	[thread overview]
Message-ID: <CAOQ4uxiz4hjMSd9POFF-vjpCPZ42MbpJ5K5_xO1sApRbDhcbCg@mail.gmail.com> (raw)
In-Reply-To: <YF5ha6TZlVocDpSY@mit.edu>

On Sat, Mar 27, 2021 at 1:34 AM Theodore Ts'o <tytso@mit.edu> wrote:
>
> I've been reading through this whole thread, and it appears to me that
> the only real, long-term solution is to rely on file system UUID's
> (for those file systems that support real 128-bit UUID's), and
> optionally, for those file systems which support it, a new, "snapshot"
> or "fs-instance" UUID.
>
> The FS UUID is pretty simple; we just need an ioctl (or similar
> interface) which returns the UUID for a particular file system.
>
> The Snapshot UUID is the one which is bit trickier.  If the underlying
> block device can supply something unique --- for example, the WWN or
> WWID which is defined by FC, ATA, SATA, SCSI, NVMe, etc. then that
> plus a partition identifier could be hashed to form a Snapshot UUID.
> LVM volumes have a LV UUID that could be used for a similar purpose.
>
> If you have a block device which doesn't relibly provide a WWN or
> WWID, or we could could imagine that a file system has a field in the
> superblock, and a file system specific program could get used to set
> that field to a random UUID, and that becomes part of the snapshot
> process.  This may be problematic for remote/network file systems
> which don't have such a concept, but life's a bitch....
>
> With that, then userspace can fetch the st_dev, st_ino, the FS UUID,
> and the Snapshot UUID, and use some combination of those fields (as
> available) to try determine whether two objects are unique or not.
>
> Is this perfect?  Heck, no.  But ultimately, this is a hard problem,
> and trying to wave our hands and create something that works given one
> set of assumptions --- and completely breaks in a diferent operating
> environment --- is going lead to angry users blaming the fs
> developers.  It's a messy problem, and I think all we can do is expose
> the entire mess to userspace, and make it be a userspace problem.
> That way, the angry users can blame the userspace developers instead.  :-)

Sounds like a plan ;-)

FWIW, if and when we will have a standard userspace API (fsinfo()?) to
export fs instance uuid to userspace, fanotify can use the uuid instead of
fsid when available (opt-in by new faotify_init() flag).

The fanotify_event_info_header contains an "info_type" field, so it's not
a problem for some events to report fsid (as today) and for other events
to report uuid, depending on availability of the information per filesystem.

Thanks,
Amir.