fscrypt, i_blkbits and network filesystems

[Jeff Layton <jlayton@kernel.org>]

I've had to table the work on fscrypt+ceph for a bit to take care of
some other issues, but I'm hoping to return to it soon, and I've started
looking at the content encryption in more detail.

One thing I'm not sure how to handle yet is fscrypt's reliance on
inode->i_blkbits. For ceph (and most netfs's), this value is a fiction.
We're not constrained to reading/writing along block boundaries.

Cephfs usually sets the blocksize in a S_ISREG inode to the same as a
"chunk" on the OSD (usu. 4M). That's a bit too large to deal with IMO,
so I'm looking at lowering that to PAGE_SIZE when fscrypt is enabled.

That's reasonable when we can do pagecache-based I/O, but sometimes
netfs's will do I/O directly from read_iter/write_iter. For ceph, we may
need to do a rmw cycle if the iovec passed down from userland doesn't
align to crypto block boundaries. Ceph has a way to do a cmp_extent
operation such that it will only do the write if nothing changed in the
interim, so we can handle that case, but it would be better not to have
to read/write more than we need.

For the netfs case, would we be better off avoiding routines that take
i_blkbits into account, and instead just work with
fscrypt_encrypt_block_inplace / fscrypt_decrypt_block_inplace, maybe
even by rolling new helpers that call them under the hood? Or, would
that cause issues that I haven't forseen, and I should just stick to
PAGE_SIZE blocks?

Thoughts?
-- 
Jeff Layton <jlayton@kernel.org>