From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Andreas Dilger <adilger@dilger.ca>
Cc: David Howells <dhowells@redhat.com>,
Eric Biggers <ebiggers@kernel.org>,
"Theodore Ts'o" <tytso@mit.edu>,
Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: Exporting ext4-specific information through fsinfo attributes
Date: Wed, 22 Apr 2020 09:12:42 -0700 [thread overview]
Message-ID: <20200422161242.GD6733@magnolia> (raw)
In-Reply-To: <BFC9114B-7D3D-4B8F-A8BB-75C2770EE36D@dilger.ca>
On Tue, Apr 21, 2020 at 04:07:43PM -0600, Andreas Dilger wrote:
> On Apr 21, 2020, at 10:17 AM, David Howells <dhowells@redhat.com> wrote:
> >
> > Darrick J. Wong <darrick.wong@oracle.com> wrote:
> >
> >> The entire superblock as a binary blob? :)
> >
> > How about the attached? Please forgive the duplication of struct
> > ext4_super_block into the test program, but it's not in the UAPI.
>
> I think (hope?) Darrick was joking?
<cough> 80% joking. It /was/ April 1st, after all. :)
Ted has said on a few occasions that one of the big stumbling blocks to
making tune2fs safe wrt mounted ext4 is that there's no way to get or
set superblock fields in a way that's kernel-mediated, and maybe the
easiest way is to export the superblock instead of playing this game
with synchronous sb writes from the kernel and the strange
mask-and-write behavior that tune2fs does.
I'm not convinced that's the best way to do that, though at least for
/reading/ the superblock I guess it beats defining a whole new structure
and ioctl.
> At least IMHO, exporting the whole superblock as a binary blob is not
> a great user interface. I guess it has the benefit of allowing access
> to various non-standard fields without accessing the device directly.
> Kind of like SCSI mode pages, but that can get ugly quickly...
>
> I can definitely get behind adding generic properties like the ones
> you list below.
The other properties look fine (in principle) to me though. :)
--D
> >
> > David
> > ---
> > fsinfo: Add support to ext4
> >
> > Add support to ext4, including the following:
> >
> > (1) FSINFO_ATTR_SUPPORTS: Information about supported STATX attributes and
> > support for ioctls like FS_IOC_[GS]ETFLAGS and FS_IOC_FS[GS]ETXATTR.
> >
> > (2) FSINFO_ATTR_FEATURES: Information about features supported by an ext4
> > filesystem, such as whether version counting, birth time and name case
> > folding are in operation.
> >
> > (3) FSINFO_ATTR_VOLUME_NAME: The volume name from the superblock.
> >
> > (4) FSINFO_ATTR_EXT4_SUPERBLOCK: The entirety of the on disk-format
> > superblock record as an opaque blob.
> >
> > Signed-off-by: David Howells <dhowells@redhat.com>
> > cc: "Theodore Ts'o" <tytso@mit.edu>
> > cc: Andreas Dilger <adilger.kernel@dilger.ca>
> > cc: "Darrick J. Wong" <darrick.wong@oracle.com>
> > cc: Eric Biggers <ebiggers@kernel.org>
> > cc: linux-ext4@vger.kernel.org
>
> Cheers, Andreas
>
>
>
>
>
next prev parent reply other threads:[~2020-04-22 16:12 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-01 7:39 Exporting ext4-specific information through fsinfo attributes David Howells
2020-04-01 15:18 ` Darrick J. Wong
2020-04-21 16:17 ` David Howells
2020-04-21 22:07 ` Andreas Dilger
2020-04-22 14:27 ` David Howells
2020-04-22 16:12 ` Darrick J. Wong [this message]
2020-07-21 9:20 ` David Howells
2020-07-21 15:37 ` Darrick J. Wong
2020-07-21 15:42 ` Darrick J. Wong
2020-07-22 8:53 ` David Howells
2020-07-22 15:25 ` Darrick J. Wong
2020-04-01 16:27 ` Eric Biggers
2020-04-01 19:05 ` Darrick J. Wong
2020-04-01 19:28 ` Eric Biggers
2020-04-01 20:36 ` Eric Biggers
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=20200422161242.GD6733@magnolia \
--to=darrick.wong@oracle.com \
--cc=adilger@dilger.ca \
--cc=dhowells@redhat.com \
--cc=ebiggers@kernel.org \
--cc=linux-ext4@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.