On Wed, May 18, 2022 at 04:50:05PM -0700, Eric Biggers wrote: > From: Eric Biggers <ebiggers@xxxxxxxxxx> > > 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@xxxxxxxxxx/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@xxxxxxxxxxxxxxxxxxx > > 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@xxxxxxxxxx> > --- Looks good to me, Reviewed-by: Christian Brauner (Microsoft) <brauner@xxxxxxxxxx>