linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Amir Goldstein <amir73il@gmail.com>
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: Fri, 26 Mar 2021 18:34:19 -0400	[thread overview]
Message-ID: <YF5ha6TZlVocDpSY@mit.edu> (raw)
In-Reply-To: <CAOQ4uxgAxUORpUJezg+oWKXEafn0o33+bP5EN+VKnoQA_KurOg@mail.gmail.com>

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.  :-)

     	      	    	      	    - Ted

  reply	other threads:[~2021-03-26 22:35 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-22 17:11 [PATCH] xfs: use a unique and persistent value for f_fsid Amir Goldstein
2021-03-22 23:03 ` Dave Chinner
2021-03-23  4:50   ` Amir Goldstein
2021-03-23  6:35     ` Darrick J. Wong
2021-03-23  6:44       ` Amir Goldstein
2021-03-23  7:26     ` Dave Chinner
2021-03-23  9:35       ` Amir Goldstein
2021-03-24  0:54         ` Dave Chinner
2021-03-24  6:53           ` Amir Goldstein
2021-03-24  7:43             ` Christoph Hellwig
2021-03-24  9:18               ` Amir Goldstein
2021-03-25 23:03                 ` Dave Chinner
2021-03-25 22:53             ` Dave Chinner
2021-03-26  6:04               ` Amir Goldstein
2021-03-26 22:34                 ` Theodore Ts'o [this message]
2021-03-27  9:14                   ` Amir Goldstein
2021-03-26 19:15     ` J. Bruce Fields
2021-03-27  9:06       ` Amir Goldstein

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YF5ha6TZlVocDpSY@mit.edu \
    --to=tytso@mit.edu \
    --cc=amir73il@gmail.com \
    --cc=bfields@fieldses.org \
    --cc=christian.brauner@ubuntu.com \
    --cc=darrick.wong@oracle.com \
    --cc=david@fromorbit.com \
    --cc=jack@suse.cz \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).