Re: [PATCH blktests] create a test for direct io offsets

[Christoph Hellwig <hch@infradead.org>]

On Mon, Nov 17, 2025 at 02:53:49PM -0700, Keith Busch wrote:
> On Tue, Oct 21, 2025 at 09:46:30PM -0700, Christoph Hellwig wrote:
> > On Tue, Oct 21, 2025 at 03:22:08PM -0600, Keith Busch wrote:
> > > On Mon, Oct 20, 2025 at 10:28:09PM -0700, Christoph Hellwig wrote:
> > > > seems like a huge win.  Any chance you could try to get this done ASAP
> > > > so that we could make the interface fully discoverable before 6.18 is
> > > > released?
> > > 
> > > I just want to make sure I am aligned to what you have in mind. Is this
> > > something like this what you're looking for? This reports the kernel's
> > > ability to handle a dio with memory that is discontiguous for a single
> > > device "sector", and reports the virtual gap requirements.
> > 
> > So, I think Christian really did not want more random stuff in statx,
> > which would lead to using fsxattr instead.
> 
> I haven't forgotten about this. I was hoping I would make sense of the
> request. It looks like only xfs makes use of fsxattr (it's the only one
> that calls copy_fsxattr_to_user()). Is the intention that every
> filesystem needs to implement support for fsxattr then?

In addition to XFS, the generic ioctl_fsgetxattr, which is directly
weird up to FS_IOC_FSGETXATTR processing uses it, XFS only has it
because it has a special version of that for xattrs.

->fileattr_get is already implemented by most file systems, so
FS_IOC_FSGETXATTR works widely.