From: "Theodore Ts'o" <tytso@mit.edu>
To: Kent Overstreet <kent.overstreet@linux.dev>
Cc: brauner@kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/7] filesystem visibililty ioctls
Date: Mon, 12 Feb 2024 17:47:40 -0500 [thread overview]
Message-ID: <20240212224740.GA394352@mit.edu> (raw)
In-Reply-To: <kq2mh37o6goojweon37kct4r3oitiwmrbjigurc566djrdu5hd@u56irarzd452>
On Wed, Feb 07, 2024 at 03:26:55PM -0500, Kent Overstreet wrote:
> You've still got the ext4 version, we're not taking that away. But I
> don't think other filesystems will want to deal with the hassle of
> changing UUIDs at runtime, since that's effectively used for API access
> via sysfs and debugfs.
Thanks. I misunderstood the log. I didn't realize this was just about
not hoisting the ioctl to the VFS level, and dropping the generic uuid
set.
I'm not convinced that we should be using the UUID for kernel API
access, if for no other reason that not all file systems have UUID's.
Sure, modern file systems have UUID's, and individual file systems
might have to have specific features that don't play well with UUID's
changing while the file system is mounted. But I'm hoping that we
don't add any new interfaces that rely on using the UUID for API
access at the VFS layer. After all, ext2 (not just ext3 and ext4) has
supported changing the UUID while the file system has been mounted for
*decades*.
- Ted
next prev parent reply other threads:[~2024-02-12 22:47 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-06 20:18 [PATCH v2 0/7] filesystem visibililty ioctls Kent Overstreet
2024-02-06 20:18 ` [PATCH v2 1/7] fs: super_set_uuid() Kent Overstreet
2024-02-06 21:45 ` Dave Chinner
2024-02-06 20:18 ` [PATCH v2 2/7] overlayfs: Convert to super_set_uuid() Kent Overstreet
2024-02-06 21:48 ` Dave Chinner
2024-02-07 6:19 ` Amir Goldstein
2024-02-06 20:18 ` [PATCH v2 3/7] fs: FS_IOC_GETUUID Kent Overstreet
2024-02-06 20:29 ` Randy Dunlap
2024-02-06 22:01 ` Dave Chinner
2024-02-06 22:37 ` Kent Overstreet
2024-02-07 0:20 ` Dave Chinner
2024-02-07 13:05 ` Brian Foster
2024-02-08 21:57 ` Kent Overstreet
2024-02-12 12:47 ` Brian Foster
2024-02-12 13:39 ` Kent Overstreet
2024-02-12 16:53 ` Brian Foster
2024-02-06 20:18 ` [PATCH v2 4/7] fat: Hook up sb->s_uuid Kent Overstreet
2024-02-06 20:18 ` [PATCH v2 5/7] fs: FS_IOC_GETSYSFSNAME Kent Overstreet
2024-02-06 22:26 ` Dave Chinner
2024-02-07 0:52 ` Kent Overstreet
2024-02-06 20:18 ` [PATCH v2 6/7] xfs: add support for FS_IOC_GETSYSFSNAME Kent Overstreet
2024-02-06 20:18 ` [PATCH v2 7/7] bcachefs: " Kent Overstreet
2024-02-07 1:47 ` [PATCH v2 0/7] filesystem visibililty ioctls Eric Biggers
2024-02-07 2:09 ` Kent Overstreet
2024-02-07 17:40 ` Theodore Ts'o
2024-02-07 20:26 ` Kent Overstreet
2024-02-08 9:01 ` Christian Brauner
2024-02-12 22:47 ` Theodore Ts'o [this message]
2024-02-12 23:24 ` Kent Overstreet
2024-02-08 9:48 ` Christian Brauner
2024-02-08 18:16 ` Kent Overstreet
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=20240212224740.GA394352@mit.edu \
--to=tytso@mit.edu \
--cc=brauner@kernel.org \
--cc=kent.overstreet@linux.dev \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@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).