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

On Fri, Jul 10, 2026 at 04:58:12PM -0600, Keith Busch wrote:
> On Fri, Jul 10, 2026 at 05:53:28PM -0400, Eric Biggers wrote:
> > On Fri, Jul 10, 2026 at 02:06:41PM -0700, Keith Busch via Linux-f2fs-devel wrote:
> > > From: Keith Busch <[email protected]>
> > > 
> > > The attributes reported through statx are incomplete for applications to
> > > fully know exactly how IO construction is valid or not. The statx call
> > > can report minimum memory alignment and total granularity, but it
> > > doesn't show the underlying gap boundary requirements or max segments
> > > per granule.
> > > 
> > > This series adds the minimum to the extended file attributes through
> > > file_getattr. I hear this is the preferred interface for reporting such
> > > things over adding more fields to statx. In order to get everything
> > > under a single syscall, some of the attributes are duplicated from
> > > statx.
> > 
> > Okay, in v2 we at least now know that the existing statx UAPI was
> > considered.  Could you give a specific real-world example (with the
> > actual values of each parameter) where it's not sufficient?  Without
> > that there isn't really any way to evaluate this proposal.
> 
> Yes, we can consider nvme. This protocol supports two different transfer
> modes called PRP and SGL. PRP requires 4k aligned segments, though you
> can have an arbitrary 4-byte aligned offset at the start. SGL on the
> other hand allows completely arbitrary size and alignments for each
> segment.
> 
> statx reports information sufficient to know that you can have dword
> aligned page offsets for a virtually contiguous buffer, but it doesn't
> report PRP's boundary gap requirement, so applications can't tell if the
> file follows PRP or SGL rules for direct-io.
> 
> And if you have a device using SGL, statx doesn't report the max number
> of sub-sector segments you can submit in a single command.
> 
> This series provides both limits so user space has the complete picture.
> 
> A typical nvme that supports only PRP has a DMA alignment of 4 bytes, a
> 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?

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?

> 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?

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.

- Eric


_______________________________________________
Linux-f2fs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel