On Tue, Jul 06, 2021 at 10:29:34PM -0700, Satya Tangirala wrote: > When a bio has an encryption context, its size must be aligned to its > crypto data unit size. A bio must not be split in the middle of a data > unit. Currently, bios are split at logical block boundaries, but a crypto > data unit size might be larger than the logical block size - e.g. a machine > could be using fscrypt (which uses 4K crypto data units) with an eMMC block > device with inline encryption hardware that has a logical block size of 512 > bytes. > > Right now, the only user of blk-crypto is fscrypt (on ext4 and f2fs), which > (currently) only submits bios where the size of each segment is a multiple > of data_unit_size. That happens to avoid most of the cases where bios > could be split in the middle of a data unit. However, when support for > direct I/O on encrypted files is added, or when support for filesystem > metadata encryption is added, it will be possible for bios to have segment > lengths that are multiples of the logical block size, but not multiples of > the crypto data unit size. So the block layer needs to start handling this > case appropriately. I'm still not sold on this case yet. sector size aligned I/O is an optional feature, and I don't think it is worth this overhead. And while file systems metadata can be smaller than the file system block size in a few cases (e.g. XFS log writes), that is usually an extra performance optimization and can be trivially disabled in mkfs.
