[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220520115237.w2oa5bdzyzhkgwin@wittgenstein>
Date: Fri, 20 May 2022 13:52:37 +0200
From: Christian Brauner <brauner@...nel.org>
To: Eric Biggers <ebiggers@...nel.org>
Cc: linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org,
linux-f2fs-devel@...ts.sourceforge.net, linux-xfs@...r.kernel.org,
linux-api@...r.kernel.org, linux-fscrypt@...r.kernel.org,
linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
Keith Busch <kbusch@...nel.org>
Subject: Re: [RFC PATCH v2 1/7] statx: add I/O alignment information
On Wed, May 18, 2022 at 04:50:05PM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@...gle.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@...gle.com>
> ---
Looks good to me,
Reviewed-by: Christian Brauner (Microsoft) <brauner@...nel.org>
Powered by blists - more mailing lists