Re: [PATCH 00/13] block, ext4: allow encryption with a block size larger than the page size

[Baokun Li <libaokun@linux.alibaba.com>]

Hi Eric, Thank you for your feedback!
On 2026/10/16 02:53, Eric Biggers wrote:
> On Mon, Oct 12, 2026 at 01:09:45AM +0800, Baokun Li wrote:
>> Motivation
>> ==========
>>
>> ext4 supports a block size larger than the page size (LBS), e.g. a 32k
>> block size on a machine with 4k pages [1].  Encryption, however, is
>> still refused on such a filesystem: file contents used to be encrypted
>> page by page in the fs-layer path, which cannot handle a folio that
>> covers several data units, so the checks that refuse encryption with
>> such a block size stayed in place.
>>
>> Since commit 5acc6f649a68 ("fscrypt: Always use blk-crypto for
>> contents on block-based filesystems") file contents are always
>> encrypted through blk-crypto.  Inline encryption hardware can already
>> en/decrypt a data unit that spans several pages, but the fallback and
>> the block layer cannot carry such a data unit:
>>
>>   1. blk-crypto-fallback en/decrypts a data unit with the bio_vecs of
>>      a single page-clamped segment, so a larger data unit fails with
>>      BLK_STS_INVAL;
>>   2. the block layer requires every bio_vec of an encrypted bio to be
>>      data unit aligned, and splits such a bio without rounding the
>>      split size down to the data unit size;
>>   3. iomap cuts the direct I/O bios of an encrypted file only at the
>>      logical block size of the device, so a bio can end in the middle
>>      of a data unit.
>>
>> This series adds the missing pieces on all three layers, removes the
>> refusals, and enables large folios for encrypted files on the way.
>>
>> [1]: https://lore.kernel.org/all/20251121090654.631996-1-libaokun@huaweicloud.com
> A high-level question: most of the complexity in this series is to
> support crypto_data_unit_size > PAGE_SIZE, despite the actual goal being
> to support fs_block_size > PAGE_SIZE.  It's left unstated that the
> default of crypto_data_unit_size == fs_block_size is used.  However,
> ext4 and f2fs already support crypto_data_unit_size < fs_block_size.
>
> Would leaving the crypto_data_unit_size at e.g. 4 KiB while increasing
> fs_block_size be a simpler way to achieve the goal of this series?

I initially followed the LBS approach of lifting the page-size
restriction, keeping the existing default crypto_data_unit_size
equal to fs_block_size. I had not considered using sub-block DUs.

After your reply, I implemented a variant using min(bs, PS) for
new default v2 policies, recording a smaller DU explicitly on disk.
This avoids patches 3-6 and the per-bvec alignment relaxation in
patch 10, and is indeed much simpler.

Both variants retain large-folio support and showed similar gains,
about twice their respective 4K-block controls. Although 32K DUs reduced
decryption calls eightfold, I did not observe a consistent additional
throughput benefit, or CPU savings at matched bandwidth, in the tested
workloads.

> Or do you feel that would be incomplete, and you'd indeed like to
> support crypto_data_unit_size = fs_block_size > PAGE_SIZE?

However, keeping DU = bs has a compatibility advantage for existing
encrypted filesystems.

For example, a 64K-block filesystem created with a default v2 policy
on a 64K-page machine uses 64K DUs. Supporting DU > PAGE_SIZE would
allow a 4K-page machine to use that format without re-encryption,
assuming the other policy and backend requirements are met.

This also covers otherwise-supported legacy v1 policies, which cannot
encode smaller DUs.

Explicit 4K v2 DUs can also be portable across page sizes, but
choosing a smaller DU for new files does not make existing large-DU
ciphertext readable on a smaller-page machine. I have not yet tested
the cross-page-size migration.

If you think supporting DU = bs > PS makes this series too broad,
I can use the simpler sub-block version in the next revision and
develop larger-DU support separately.

Looking forward to hearing your thoughts.


Thanks,
Baokun