All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Brauner <brauner@kernel.org>
To: Eric Biggers <ebiggers@kernel.org>
Cc: linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-xfs@vger.kernel.org, linux-api@vger.kernel.org,
	linux-fscrypt@vger.kernel.org, linux-block@vger.kernel.org,
	linux-kernel@vger.kernel.org, Keith Busch <kbusch@kernel.org>
Subject: Re: [RFC PATCH v2 1/7] statx: add I/O alignment information
Date: Fri, 20 May 2022 13:52:37 +0200	[thread overview]
Message-ID: <20220520115237.w2oa5bdzyzhkgwin@wittgenstein> (raw)
In-Reply-To: <20220518235011.153058-2-ebiggers@kernel.org>

On Wed, May 18, 2022 at 04:50:05PM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
> 
> Traditionally, the conditions for when DIO (direct I/O) is supported
> were fairly simple: filesystems either supported DIO aligned to the
> block device's logical block size, or didn't support DIO at all.
> 
> However, due to filesystem features that have been added over time (e.g,
> data journalling, inline data, encryption, verity, compression,
> checkpoint disabling, log-structured mode), the conditions for when DIO
> is allowed on a file have gotten increasingly complex.  Whether a
> particular file supports DIO, and with what alignment, can depend on
> various file attributes and filesystem mount options, as well as which
> block device(s) the file's data is located on.
> 
> XFS has an ioctl XFS_IOC_DIOINFO which exposes this information to
> applications.  However, as discussed
> (https://lore.kernel.org/linux-fsdevel/20220120071215.123274-1-ebiggers@kernel.org/T/#u),
> this ioctl is rarely used and not known to be used outside of
> XFS-specific code.  It also was never intended to indicate when a file
> doesn't support DIO at all, and it only exposes the minimum I/O
> alignment, not the optimal I/O alignment which has been requested too.
> 
> Therefore, let's expose this information via statx().  Add the
> STATX_IOALIGN flag and three fields associated with it:
> 
> * stx_mem_align_dio: the alignment (in bytes) required for user memory
>   buffers for DIO, or 0 if DIO is not supported on the file.
> 
> * stx_offset_align_dio: the alignment (in bytes) required for file
>   offsets and I/O segment lengths for DIO, or 0 if DIO is not supported
>   on the file.  This will only be nonzero if stx_mem_align_dio is
>   nonzero, and vice versa.
> 
> * stx_offset_align_optimal: the alignment (in bytes) suggested for file
>   offsets and I/O segment lengths to get optimal performance.  This
>   applies to both DIO and buffered I/O.  It differs from stx_blocksize
>   in that stx_offset_align_optimal will contain the real optimum I/O
>   size, which may be a large value.  In contrast, for compatibility
>   reasons stx_blocksize is the minimum size needed to avoid page cache
>   read/write/modify cycles, which may be much smaller than the optimum
>   I/O size.  For more details about the motivation for this field, see
>   https://lore.kernel.org/r/20220210040304.GM59729@dread.disaster.area
> 
> Note that as with other statx() extensions, if STATX_IOALIGN isn't set
> in the returned statx struct, then these new fields won't be filled in.
> This will happen if the filesystem doesn't support STATX_IOALIGN, or if
> the file isn't a regular file.  (It might be supported on block device
> files in the future.)  It might also happen if the caller didn't include
> STATX_IOALIGN in the request mask, since statx() isn't required to
> return information that wasn't requested.
> 
> This commit adds the VFS-level plumbing for STATX_IOALIGN.  Individual
> filesystems will still need to add code to support it.
> 
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> ---

Looks good to me,
Reviewed-by: Christian Brauner (Microsoft) <brauner@kernel.org>

WARNING: multiple messages have this Message-ID (diff)
From: Christian Brauner <brauner@kernel.org>
To: Eric Biggers <ebiggers@kernel.org>
Cc: linux-block@vger.kernel.org, linux-api@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-xfs@vger.kernel.org, Keith Busch <kbusch@kernel.org>,
	linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-ext4@vger.kernel.org
Subject: Re: [f2fs-dev] [RFC PATCH v2 1/7] statx: add I/O alignment information
Date: Fri, 20 May 2022 13:52:37 +0200	[thread overview]
Message-ID: <20220520115237.w2oa5bdzyzhkgwin@wittgenstein> (raw)
In-Reply-To: <20220518235011.153058-2-ebiggers@kernel.org>

On Wed, May 18, 2022 at 04:50:05PM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
> 
> Traditionally, the conditions for when DIO (direct I/O) is supported
> were fairly simple: filesystems either supported DIO aligned to the
> block device's logical block size, or didn't support DIO at all.
> 
> However, due to filesystem features that have been added over time (e.g,
> data journalling, inline data, encryption, verity, compression,
> checkpoint disabling, log-structured mode), the conditions for when DIO
> is allowed on a file have gotten increasingly complex.  Whether a
> particular file supports DIO, and with what alignment, can depend on
> various file attributes and filesystem mount options, as well as which
> block device(s) the file's data is located on.
> 
> XFS has an ioctl XFS_IOC_DIOINFO which exposes this information to
> applications.  However, as discussed
> (https://lore.kernel.org/linux-fsdevel/20220120071215.123274-1-ebiggers@kernel.org/T/#u),
> this ioctl is rarely used and not known to be used outside of
> XFS-specific code.  It also was never intended to indicate when a file
> doesn't support DIO at all, and it only exposes the minimum I/O
> alignment, not the optimal I/O alignment which has been requested too.
> 
> Therefore, let's expose this information via statx().  Add the
> STATX_IOALIGN flag and three fields associated with it:
> 
> * stx_mem_align_dio: the alignment (in bytes) required for user memory
>   buffers for DIO, or 0 if DIO is not supported on the file.
> 
> * stx_offset_align_dio: the alignment (in bytes) required for file
>   offsets and I/O segment lengths for DIO, or 0 if DIO is not supported
>   on the file.  This will only be nonzero if stx_mem_align_dio is
>   nonzero, and vice versa.
> 
> * stx_offset_align_optimal: the alignment (in bytes) suggested for file
>   offsets and I/O segment lengths to get optimal performance.  This
>   applies to both DIO and buffered I/O.  It differs from stx_blocksize
>   in that stx_offset_align_optimal will contain the real optimum I/O
>   size, which may be a large value.  In contrast, for compatibility
>   reasons stx_blocksize is the minimum size needed to avoid page cache
>   read/write/modify cycles, which may be much smaller than the optimum
>   I/O size.  For more details about the motivation for this field, see
>   https://lore.kernel.org/r/20220210040304.GM59729@dread.disaster.area
> 
> Note that as with other statx() extensions, if STATX_IOALIGN isn't set
> in the returned statx struct, then these new fields won't be filled in.
> This will happen if the filesystem doesn't support STATX_IOALIGN, or if
> the file isn't a regular file.  (It might be supported on block device
> files in the future.)  It might also happen if the caller didn't include
> STATX_IOALIGN in the request mask, since statx() isn't required to
> return information that wasn't requested.
> 
> This commit adds the VFS-level plumbing for STATX_IOALIGN.  Individual
> filesystems will still need to add code to support it.
> 
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> ---

Looks good to me,
Reviewed-by: Christian Brauner (Microsoft) <brauner@kernel.org>


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

  parent reply	other threads:[~2022-05-20 11:52 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-18 23:50 [RFC PATCH v2 0/7] make statx() return I/O alignment information Eric Biggers
2022-05-18 23:50 ` [f2fs-dev] " Eric Biggers
2022-05-18 23:50 ` [RFC PATCH v2 1/7] statx: add " Eric Biggers
2022-05-18 23:50   ` [f2fs-dev] " Eric Biggers
2022-05-19  7:05   ` Christoph Hellwig
2022-05-19  7:05     ` [f2fs-dev] " Christoph Hellwig
2022-05-19 23:06   ` Darrick J. Wong
2022-05-19 23:06     ` [f2fs-dev] " Darrick J. Wong
2022-05-20  3:27     ` Dave Chinner
2022-05-20  3:27       ` [f2fs-dev] " Dave Chinner
2022-06-14  5:25       ` Eric Biggers
2022-06-14  5:25         ` [f2fs-dev] " Eric Biggers
2022-06-15 13:12         ` Christoph Hellwig
2022-06-15 13:12           ` [f2fs-dev] " Christoph Hellwig
2022-06-16  0:04           ` Eric Biggers
2022-06-16  0:04             ` [f2fs-dev] " Eric Biggers
2022-06-16  6:07             ` Christoph Hellwig
2022-06-16  6:07               ` [f2fs-dev] " Christoph Hellwig
2022-06-16  6:19               ` Eric Biggers
2022-06-16  6:19                 ` [f2fs-dev] " Eric Biggers
2022-06-16  6:29                 ` Christoph Hellwig
2022-06-16  6:29                   ` [f2fs-dev] " Christoph Hellwig
2022-05-20  6:30     ` Eric Biggers
2022-05-20  6:30       ` [f2fs-dev] " Eric Biggers
2022-05-20 11:52   ` Christian Brauner [this message]
2022-05-20 11:52     ` Christian Brauner
2022-05-27  9:02   ` Florian Weimer
2022-05-27  9:02     ` Florian Weimer
2022-05-27 16:22     ` Darrick J. Wong
2022-05-27 16:22       ` [f2fs-dev] " Darrick J. Wong
2022-05-18 23:50 ` [RFC PATCH v2 2/7] fscrypt: change fscrypt_dio_supported() to prepare for STATX_IOALIGN Eric Biggers
2022-05-18 23:50   ` [f2fs-dev] " Eric Biggers
2022-05-18 23:50 ` [RFC PATCH v2 3/7] ext4: support STATX_IOALIGN Eric Biggers
2022-05-18 23:50   ` [f2fs-dev] " Eric Biggers
2022-05-18 23:50 ` [RFC PATCH v2 4/7] f2fs: move f2fs_force_buffered_io() into file.c Eric Biggers
2022-05-18 23:50   ` [f2fs-dev] " Eric Biggers
2022-05-18 23:50 ` [RFC PATCH v2 5/7] f2fs: don't allow DIO reads but not DIO writes Eric Biggers
2022-05-18 23:50   ` [f2fs-dev] " Eric Biggers
2022-05-18 23:50 ` [RFC PATCH v2 6/7] f2fs: simplify f2fs_force_buffered_io() Eric Biggers
2022-05-18 23:50   ` [f2fs-dev] " Eric Biggers
2022-05-18 23:50 ` [RFC PATCH v2 7/7] f2fs: support STATX_IOALIGN Eric Biggers
2022-05-18 23:50   ` [f2fs-dev] " 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=20220520115237.w2oa5bdzyzhkgwin@wittgenstein \
    --to=brauner@kernel.org \
    --cc=ebiggers@kernel.org \
    --cc=kbusch@kernel.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@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 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.