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

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

On 2026/10/23 06:04, Eric Biggers wrote:
> On Fri, Oct 23, 2026 at 12:30:39AM +0800, Baokun Li wrote:
>> 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.
> I think I prefer the simpler version for now.  If someone wants to
> create encrypted files on a 64K block size filesystem on a 64K PAGE_SIZE
> system that are also readable on a 4K PAGE_SIZE system, for now they can
> just set crypto_data_unit_size = 4K.  v1 policies were deprecated 7
> years ago, so they shouldn't really factor into considerations here.
>
> Note also that setting crypto_data_unit_size too high can break write
> atomicity as well as compatibility with inline encryption hardware.
>
> (Also, the more common use case these days is that someone is
> *increasing* their page size, not decreasing it.)
>
> I understand there's been a trend to lift limitations like these and
> make every size work on every system.  But the large crypto data unit
> sizes are difficult to implement correctly, and the proposed
> implementation slows down common cases that matter.  Let's focus on
> fs_block_size > PAGE_SIZE by itself first.

Agreed, that makes sense. I'll switch to sub-block data units
in the next revision.

Thank you for your feedback!


Cheers,
Baokun