On Sun, Jun 19, 2022 at 02:30:47PM +0300, Avi Kivity wrote:

quoted

* stx_dio_offset_align: 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_dio_mem_align is
   nonzero, and vice versa.

If you consider AIO, this is actually three alignments:

1. offset alignment for reads (sector size in XFS)

2. offset alignment for overwrites (sector size in XFS since ed1128c2d0c87e,
block size earlier)

3. offset alignment for appending writes (block size)


This is critical for linux-aio since violation of these alignments will
stall the io_submit system call. Perhaps io_uring handles it better by
bouncing to a workqueue, but there is a significant performance and latency
penalty for that.

I think you are mixing things up here.  We actually have two limits that
matter:

 a) the hard limit, which if violated will return an error.
    This has been sector size for all common file systems for years,
    but can be bigger than that with fscrypt in the game (which
    triggered this series)
 b) an optimal write size, which can be done asynchronous and
    without exclusive locking.
    This is what your cases 2) and 3) above refer to.

Exposting this additional optimal performance size might be a good idea
in addition to what is proposed here, even if matters a little less
with io_uring.  But I'm not sure I'd additional split it into append
vs overwrite vs hole filling but just round up to the maximum of those.