From: Eric Biggers <ebiggers@kernel.org> To: "Darrick J. Wong" <djwong@kernel.org> Cc: Christoph Hellwig <hch@infradead.org>, linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-xfs@vger.kernel.org, Dave Chinner <david@fromorbit.com>, Theodore Ts'o <tytso@mit.edu>, Jaegeuk Kim <jaegeuk@kernel.org>, Chao Yu <chao@kernel.org> Subject: Re: [PATCH v10 0/5] add support for direct I/O with fscrypt using blk-crypto Date: Thu, 20 Jan 2022 12:39:14 -0800 [thread overview] Message-ID: <YenIcshA706d/ziV@sol.localdomain> (raw) In-Reply-To: <20220120171027.GL13540@magnolia> 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
WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org> To: "Darrick J. Wong" <djwong@kernel.org> Cc: linux-xfs@vger.kernel.org, Theodore Ts'o <tytso@mit.edu>, Dave Chinner <david@fromorbit.com>, linux-f2fs-devel@lists.sourceforge.net, Christoph Hellwig <hch@infradead.org>, linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org, Jaegeuk Kim <jaegeuk@kernel.org>, linux-ext4@vger.kernel.org Subject: Re: [f2fs-dev] [PATCH v10 0/5] add support for direct I/O with fscrypt using blk-crypto Date: Thu, 20 Jan 2022 12:39:14 -0800 [thread overview] Message-ID: <YenIcshA706d/ziV@sol.localdomain> (raw) In-Reply-To: <20220120171027.GL13540@magnolia> 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 _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
next prev parent reply other threads:[~2022-01-20 20:39 UTC|newest] Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-01-20 7:12 [PATCH v10 0/5] add support for direct I/O with fscrypt using blk-crypto Eric Biggers 2022-01-20 7:12 ` [f2fs-dev] " Eric Biggers 2022-01-20 7:12 ` [PATCH v10 1/5] fscrypt: add functions for direct I/O support Eric Biggers 2022-01-20 7:12 ` [f2fs-dev] " Eric Biggers 2022-01-20 8:27 ` Christoph Hellwig 2022-01-20 8:27 ` [f2fs-dev] " Christoph Hellwig 2022-01-20 9:04 ` Eric Biggers 2022-01-20 9:04 ` [f2fs-dev] " Eric Biggers 2022-01-21 7:10 ` Christoph Hellwig 2022-01-21 7:10 ` [f2fs-dev] " Christoph Hellwig 2022-01-20 7:12 ` [PATCH v10 2/5] iomap: support direct I/O with fscrypt using blk-crypto Eric Biggers 2022-01-20 7:12 ` [f2fs-dev] " Eric Biggers 2022-01-20 8:28 ` Christoph Hellwig 2022-01-20 8:28 ` [f2fs-dev] " Christoph Hellwig 2022-01-20 7:12 ` [PATCH v10 3/5] ext4: " Eric Biggers 2022-01-20 7:12 ` [f2fs-dev] " Eric Biggers 2022-01-20 7:12 ` [PATCH v10 4/5] f2fs: " Eric Biggers 2022-01-20 7:12 ` [f2fs-dev] " Eric Biggers 2022-01-20 7:12 ` [PATCH v10 5/5] fscrypt: update documentation for direct I/O support Eric Biggers 2022-01-20 7:12 ` [f2fs-dev] " Eric Biggers 2022-01-20 8:30 ` [f2fs-dev] [PATCH v10 0/5] add support for direct I/O with fscrypt using blk-crypto Christoph Hellwig 2022-01-20 8:30 ` Christoph Hellwig 2022-01-20 17:10 ` Darrick J. Wong 2022-01-20 17:10 ` [f2fs-dev] " Darrick J. Wong 2022-01-20 20:39 ` Eric Biggers [this message] 2022-01-20 20:39 ` Eric Biggers 2022-01-20 21:00 ` Darrick J. Wong 2022-01-20 21:00 ` [f2fs-dev] " Darrick J. Wong 2022-01-20 22:04 ` Dave Chinner 2022-01-20 22:04 ` [f2fs-dev] " Dave Chinner 2022-01-20 22:48 ` Eric Biggers 2022-01-20 22:48 ` [f2fs-dev] " Eric Biggers 2022-01-20 23:57 ` Dave Chinner 2022-01-20 23:57 ` [f2fs-dev] " Dave Chinner 2022-01-21 2:36 ` Darrick J. Wong 2022-01-21 2:36 ` [f2fs-dev] " Darrick J. Wong 2022-01-21 7:12 ` Christoph Hellwig 2022-01-21 7:12 ` [f2fs-dev] " Christoph Hellwig 2022-01-23 23:03 ` Dave Chinner 2022-01-23 23:03 ` [f2fs-dev] " Dave Chinner 2022-02-09 1:10 ` Eric Biggers 2022-02-09 1:10 ` Eric Biggers 2022-02-10 4:03 ` Dave Chinner 2022-02-10 4:03 ` [f2fs-dev] " Dave Chinner
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=YenIcshA706d/ziV@sol.localdomain \ --to=ebiggers@kernel.org \ --cc=chao@kernel.org \ --cc=david@fromorbit.com \ --cc=djwong@kernel.org \ --cc=hch@infradead.org \ --cc=jaegeuk@kernel.org \ --cc=linux-ext4@vger.kernel.org \ --cc=linux-f2fs-devel@lists.sourceforge.net \ --cc=linux-fscrypt@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-xfs@vger.kernel.org \ --cc=tytso@mit.edu \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.