Re: [PATCHv2 0/5] direct-io file extended attributes

[Keith Busch <kbusch@kernel.org>]

On Fri, Jul 10, 2026 at 08:24:12PM -0400, Eric Biggers wrote:
> On Fri, Jul 10, 2026 at 04:58:12PM -0600, Keith Busch wrote:
> > dio offset alignment of 4k, and a virtual boundary of 4k.
> 
> So each segment's length has to be a multiple of 4k, *and* it has to end
> on a 4k aligned memory address?  That implies the segment begins at a 4k
> aligned memory address as well, which is just stx_dio_mem_align=4k.
> 
> What am I missing?

I'm apparently poorly explaining PRPs, but I hear this is a common
experience.

Simply put, any virtually contiguous buffer that starts at a dword
aligned address is a valid io vector, no matter how many pages it spans.
It doesn't matter where it starts or where it ends, but every page in
the middle obviously starts and ends on their page boundary.

Simple case: pread/pwrite. You can consult statx to know you can provide
any dword aligned buffer with an aligned length, and that's a valid
direct IO.

What I'm trying to enable here is the vectored preadv/pwritev type paths
for hardware that don't need to subscribe to PRP constraints.
 
> What is a specific example of an I/O request that you'd like to be able
> to submit that the existing UAPI can't declare support for?

I want to support NVMe SGL. This allows virtually *discontiguous*
segments that we currently can't distinguish with what statx reports.
I'm trying to report limits that let applications know what constraints
they're dealing with.

> > If SGL were supported, there would be no virtual boundary gap, and max
> > segments is 256.
> 
> Can you elaborate on why DIO users need to know max_segments?

 * Logical block is 4k.

 * DMA granule is 4 bytes.

 * Max segments is 256.

That's very typical NVMe device contraints under SGL capabilities with
the linux driver.

You can provide 4 byte vectors as needed, but you'll hit the max
segments limit before you have a valid IO if they're all that small.
The average size needs to be larger, so we need to communicate that
somehow.

To be clear, I'm not interested in trying to enable applications
dispatching thousands of 4-byte vectors to do an IO. That's a stupid
application. The applications I'm trying to enable have unpredictable
offsets such that a tiny fraction of vectors are indeed that small, but
that's not a typical vector for the payload. But I can't enable just
some without generically enabling all.

> I'm worried about the UAPI duplication, as well as it going to be very
> difficult for userspace to correctly use this information.  With just
> the two alignments there's at least a chance of them getting it right.
> If we throw virt_boundary_mask and max_segments into the mix, I don't
> think there's much chance.

The blktests framework test case "block/043" does this with great
success with these exact parameters, but it takes these paramters from
the sysfs attributes. The same test works with filesystems too, but I
haven't gotten around to porting it to fstests because it's gating on
having this series.