On Mon, Jul 13, 2020 at 11:36:19AM -0700, Eric Biggers wrote: > On Fri, Jul 10, 2020 at 06:34:06AM +0100, Christoph Hellwig wrote: > > On Thu, Jul 09, 2020 at 07:47:48PM +0000, Satya Tangirala wrote: > > > From: Eric Biggers <ebiggers@xxxxxxxxxx> > > > > > > Set bio crypt contexts on bios by calling into fscrypt when required, > > > and explicitly check for DUN continuity when adding pages to the bio. > > > (While DUN continuity is usually implied by logical block contiguity, > > > this is not the case when using certain fscrypt IV generation methods > > > like IV_INO_LBLK_32). > > > > I know it is asking you for more work, but instead of adding more > > features to the legacy direct I/O code, could you just switch the user > > of it (I guess this is for f2f2?) to the iomap one? > > Eventually we should do that, as well as convert f2fs's fiemap, bmap, and llseek > to use iomap. However there's a nontrivial barrier to entry, at least for > someone who isn't an expert in iomap, especially since f2fs currently doesn't > use iomap at all and thus doesn't have an iomap_ops implementation. And using > ext4 as an example, there will be some subtle cases that need to be handled. > > Satya says he's looking into it; we'll see what he can come up with and what the > f2fs developers say. > > If it turns out to be difficult and people think this patchset is otherwise > ready, we probably shouldn't hold it up on that. This is a very small patch, > and Satya and I have to maintain it for years in downstream kernels anyway, so > it will be used and tested regardless. It would also be nice to allow userspace > (e.g. xfstests) to assume that if the inlinecrypt mount option is supported, > then direct I/O is supported too, without having to handle intermediate kernel > releases where inlinecrypt was supported but not direct I/O. > As Eric pointed out, it doesn't seem to be completely straightforward to move f2fs to using iomap - I'm still looking into it, but for now I've sent out v2 (and v3 just because I forgot to add a changelog to v2) with the changes to fs/direct-io.c as is from v1, but (again, for the reasons Eric points out) I think it'd be better not to hold this patch up for that. > - Eric