On Thu, Jan 20, 2022 at 09:10:27AM -0800, Darrick J. Wong wrote:
> On Thu, Jan 20, 2022 at 12:30:23AM -0800, Christoph Hellwig wrote:
> > On Wed, Jan 19, 2022 at 11:12:10PM -0800, Eric Biggers wrote:
> > >
> > > Given the above, as far as I know the only remaining objection to this
> > > patchset would be that DIO constraints aren't sufficiently discoverable
> > > by userspace. Now, to put this in context, this is a longstanding issue
> > > with all Linux filesystems, except XFS which has XFS_IOC_DIOINFO. It's
> > > not specific to this feature, and it doesn't actually seem to be too
> > > important in practice; many other filesystem features place constraints
> > > on DIO, and f2fs even *only* allows fully FS block size aligned DIO.
> > > (And for better or worse, many systems using fscrypt already have
> > > out-of-tree patches that enable DIO support, and people don't seem to
> > > have trouble with the FS block size alignment requirement.)
> >
> > It might make sense to use this as an opportunity to implement
> > XFS_IOC_DIOINFO for ext4 and f2fs.
>
> Hmm. A potential problem with DIOINFO is that it doesn't explicitly
> list the /file/ position alignment requirement:
>
> struct dioattr {
> __u32 d_mem; /* data buffer memory alignment */
> __u32 d_miniosz; /* min xfer size */
> __u32 d_maxiosz; /* max xfer size */
> };
Well, the comment above struct dioattr says:
/*
* Direct I/O attribute record used with XFS_IOC_DIOINFO
* d_miniosz is the min xfer size, xfer size multiple and file seek offset
* alignment.
*/
So d_miniosz serves that purpose already.
>
> Since I /think/ fscrypt requires that directio writes be aligned to file
> block size, right?
The file position must be a multiple of the filesystem block size, yes.
Likewise for the "minimum xfer size" and "xfer size multiple", and the "data
buffer memory alignment" for that matter. So I think XFS_IOC_DIOINFO would be
good enough for the fscrypt direct I/O case.
The real question is whether there are any direct I/O implementations where
XFS_IOC_DIOINFO would *not* be good enough, for example due to "xfer size
multiple" != "file seek offset alignment" being allowed. In that case we would
need to define a new ioctl that is more general (like the one you described
below) rather than simply uplifting XFS_IOC_DIOINFO.
More general is nice, but it's not helpful if no one will actually use the extra
information. So we need to figure out what is actually useful.
> How about something like this:
>
> struct dioattr2 {
> __u32 d_mem; /* data buffer memory alignment */
> __u32 d_miniosz; /* min xfer size */
> __u32 d_maxiosz; /* max xfer size */
>
> /* file range must be aligned to this value */
> __u32 d_min_fpos;
>
> /* for optimal performance, align file range to this */
> __u32 d_opt_fpos;
>
> __u32 d_padding[11];
> };
>
- Eric
