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
![]() |