On Thu, Jan 20, 2022 at 12:39:14PM -0800, Eric Biggers wrote:
> 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.
Oh, ok then. In that case, just hoist XFS_IOC_DIOINFO to the VFS and
add a couple of implementations for ext4 and f2fs, and I think that'll
be enough to get the fscrypt patchset moving again.
> 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.
I don't think there are any currently, but if anyone ever redesigns
DIOINFO we might as well make all those pieces explicit.
> 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.
<nod> Clearly I haven't wanted d_opt_fpos badly enough to propose
revving the ioctl. ;)
--D
>
> > 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
