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@xxxxxxxxxx>
|