public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Dave Chinner <david@fromorbit.com>
Cc: "Kiselev, Oleg" <okiselev@amazon.com>,
	Kent Overstreet <kent.overstreet@linux.dev>,
	Theodore Ts'o <tytso@mit.edu>,
	"torvalds@linux-foundation.org" <torvalds@linux-foundation.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Christian Brauner <brauner@kernel.org>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH 3/3] ext4: Add support for FS_IOC_GETFSSYSFSPATH
Date: Tue, 19 Mar 2024 18:49:27 -0700	[thread overview]
Message-ID: <20240320014927.GT6184@frogsfrogsfrogs> (raw)
In-Reply-To: <Zfi+v/9vF+mfZ4Bl@dread.disaster.area>

On Tue, Mar 19, 2024 at 09:22:55AM +1100, Dave Chinner wrote:
> On Mon, Mar 18, 2024 at 09:51:04PM +0000, Kiselev, Oleg wrote:
> > On 3/15/24, 09:51, "Kent Overstreet" <kent.overstreet@linux.dev <mailto:kent.overstreet@linux.dev>> wrote:
> > > On Fri, Mar 15, 2024 at 12:45:50PM -0400, Theodore Ts'o wrote:
> > > > On Thu, Mar 14, 2024 at 11:53:02PM -0400, Kent Overstreet wrote:
> > > > > the new sysfs path ioctl lets us get the /sys/fs/ path for a given
> > > > > filesystem in a fs agnostic way, potentially nudging us towards
> > > > > standarizing some of our reporting.
> > > > >
> > > > > --- a/fs/ext4/super.c
> > > > > +++ b/fs/ext4/super.c
> > > > > @@ -5346,6 +5346,7 @@ static int __ext4_fill_super(struct fs_context *fc, struct super_block *sb)
> > > > > sb->s_quota_types = QTYPE_MASK_USR | QTYPE_MASK_GRP | QTYPE_MASK_PRJ;
> > > > > #endif
> > > > > super_set_uuid(sb, es->s_uuid, sizeof(es->s_uuid));
> > > > > + super_set_sysfs_name_bdev(sb);
> > > >
> > > > Should we perhaps be hoisting this call up to the VFS layer, so that
> > > > all file systems would benefit?
> > >
> > >
> > > I did as much hoisting as I could. For some filesystems (single device
> > > filesystems) the sysfs name is the block device, for the multi device
> > > filesystems I've looked at it's the UUID.
> > 
> > Why not use the fs UUID for all cases, single device and multi device?
> 
> Because the sysfs directory heirachy has already been defined for
> many filesystems, and technically sysfs represents a KABI that we
> can't just break for the hell of it.
> 
> e.g. changing everything to use uuid will break fstests
> infrastructure because it assumes that it can derive the sysfs dir
> location for the filesystem from the *device name* the filesystem is
> mounted on. btrfs has a special implementation of that derivation
> that runs the btrfs command to retreive the UUID of the filesysem.
> 
> So, yes, while we could technically change it, we break anything in
> userspace that has introduced a dependency on bdev name as the sysfs
> fs identifier. We're not going to break userspace like this,
> especially as it is trivial to avoid.

Wellll... some day in the far kumbaya future, everyone will call
GETSYSFSPATH and they won't have to know or care what each fs does under
the covers.  So who cares? 8-)

How about using sysfs_create_link for non -o nouuid filesystems so that
/sys/fs/xfs/$uuid actually goes somewhere?

<shrug> Don't really care much myself either way.

--D

> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com
> 

  reply	other threads:[~2024-03-20  1:49 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-15  3:52 [PATCH 0/3] bit more FS_IOC_GETFSUUID, FS_IOC_GETFSSYSFSPATH Kent Overstreet
2024-03-15  3:53 ` [PATCH 1/3] bcachefs: Switch to uuid_to_fsid() Kent Overstreet
2024-03-15  3:53 ` [PATCH 2/3] bcachefs: Initialize super_block->s_uuid Kent Overstreet
2024-03-15  3:53 ` [PATCH 3/3] ext4: Add support for FS_IOC_GETFSSYSFSPATH Kent Overstreet
2024-03-15 16:45   ` Theodore Ts'o
2024-03-15 16:50     ` Kent Overstreet
2024-03-18 21:51       ` Kiselev, Oleg
2024-03-18 22:22         ` Dave Chinner
2024-03-20  1:49           ` Darrick J. Wong [this message]
2024-03-22 23:03   ` Andreas Dilger
2024-05-02 20:00 ` [PATCH 0/3] bit more FS_IOC_GETFSUUID, FS_IOC_GETFSSYSFSPATH Theodore Ts'o

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=20240320014927.GT6184@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=adilger.kernel@dilger.ca \
    --cc=brauner@kernel.org \
    --cc=david@fromorbit.com \
    --cc=kent.overstreet@linux.dev \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=okiselev@amazon.com \
    --cc=torvalds@linux-foundation.org \
    --cc=tytso@mit.edu \
    /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