Re: [PATCH v4 00/24] ext4: enable block size larger than page size

[Baokun Li <libaokun1@huawei.com>]

On 2025-11-21 18:26, Ojaswin Mujoo wrote:
> On Fri, Nov 21, 2025 at 05:06:30PM +0800, libaokun@huaweicloud.com wrote:
>> From: Baokun Li <libaokun1@huawei.com>
>>
>> Changes since v3:
>>  * Collect RVB from Jan Kara, Zhang Yi and Pankaj Raghav.
>>     (Thank you for your review!)
>>  * Patch 21: Fix lock imbalance in ext4_change_inode_journal_flag.
>>     (Suggested by Dan Carpenter)
>>
>> [v3]: https://lore.kernel.org/r/20251111142634.3301616-1-libaokun@huaweicloud.com
>>
>> Changes since v2:
>>  * Collect RVB from Jan Kara, Zhang Yi and Pankaj Raghav.
>>     (Thank you for your review!)
>>  * Patch 21: Before switching the inode journalling mode, drop all
>>     page cache of that inode and invoke filemap_write_and_wait()
>>     unconditionally. (Suggested by Jan Kara)
>>  * Patch 22: Extend fs-verity to support large folios in addition to
>>     large block size. (Suggested by Jan Kara)
>>  * Patch 24: Add a blocksize_gt_pagesize sysfs interface to help users
>>     (e.g., mke2fs) determine whether the current kernel supports bs > ps.
>>     In addition, remove the experimental tag. (Suggested by Theodore Ts'o)
>>
>> [v2]: https://lore.kernel.org/r/20251107144249.435029-1-libaokun@huaweicloud.com
>>
>> Changes since v1:
>>  * Collect RVB from Jan Kara and Zhang Yi. (Thanks for your review!)
>>  * Patch 4: Just use blocksize in the rounding.(Suggested by Jan Kara)
>>  * Patch 7: use kvmalloc() instead of allocating contiguous physical
>>     pages.(Suggested by Jan Kara)
>>  * Patch 12: Fix some typos.(Suggested by Jan Kara)
>>  * Use clearer naming: EXT4_LBLK_TO_PG() and EXT4_PG_TO_LBLK().
>>     (Suggested by Jan Kara)
>>  * Patch 21: removed. After rebasing on Ted’s latest dev branch, this
>>     patch is no longer needed.
>>  * Patch 22-23: removed. The issue was resolved by removing the WARN_ON
>>     in the MM code, so we now rely on patch [1].(Suggested by Matthew)
>>  * Add new Patch 21 to support data=journal under LBS. (Suggested by
>>     Jan Kara)
>>  * Add new Patch 22 to support fs verity under LBS.
>>  * New Patch 23: add the s_max_folio_order field instead of introducing
>>     the EXT4_MF_LARGE_FOLIO flag.
>>  * New Patch 24: rebase adaptation.
>>
>> [v1]: https://lore.kernel.org/r/20251025032221.2905818-1-libaokun@huaweicloud.com
>>
>> ======
>>
>> This series enables block size > page size (Large Block Size) in EXT4.
>>
>> Since large folios are already supported for regular files, the required
>> changes are not substantial, but they are scattered across the code.
>> The changes primarily focus on cleaning up potential division-by-zero
>> errors, resolving negative left/right shifts, and correctly handling
>> mutually exclusive mount options.
>>
>> One somewhat troublesome issue is that allocating page units greater than
>> order-1 with __GFP_NOFAIL in __alloc_pages_slowpath() can trigger an
>> unexpected WARN_ON. With LBS support, EXT4 and jbd2 may use __GFP_NOFAIL
>> to allocate large folios when reading metadata. The issue was resolved by
>> removing the WARN_ON in the MM code, so we now rely on patch [1].
>>
>> [1]: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=ee040cbd6e48
>>
>> Patch series based on Ted’s latest dev branch.
>>
>> `kvm-xfstests -c ext4/all -g auto` has been executed with no new failures.
>> `kvm-xfstests -c ext4/32k -g auto` has been executed with no new failures.
>> `kvm-xfstests -c ext4/64k -g auto` has been executed with no new failures,
>> but allocation failures for large folios may trigger warn_alloc() warnings,
>> tests with 32k or smaller block sizes have not exhibited any page allocation
>> failures.
>>
>> Here are some performance test data for your reference:
>>
>> Testing EXT4 filesystems with different block sizes, measuring
>> single-threaded dd bandwidth for BIO/DIO with varying bs values.
>>
>> Before(PAGE_SIZE=4096):
>>
>>       BIO     | bs=4k    | bs=8k    | bs=16k   | bs=32k   | bs=64k
>> --------------|----------|----------|----------|----------|------------
>>  4k           | 1.5 GB/s | 2.1 GB/s | 2.8 GB/s | 3.4 GB/s | 3.8 GB/s
>>  8k (bigalloc)| 1.4 GB/s | 2.0 GB/s | 2.6 GB/s | 3.1 GB/s | 3.4 GB/s
>>  16k(bigalloc)| 1.5 GB/s | 2.0 GB/s | 2.6 GB/s | 3.2 GB/s | 3.6 GB/s
>>  32k(bigalloc)| 1.5 GB/s | 2.1 GB/s | 2.7 GB/s | 3.3 GB/s | 3.7 GB/s
>>  64k(bigalloc)| 1.5 GB/s | 2.1 GB/s | 2.8 GB/s | 3.4 GB/s | 3.8 GB/s
>>               
>>       DIO     | bs=4k    | bs=8k    | bs=16k   | bs=32k   | bs=64k
>> --------------|----------|----------|----------|----------|------------
>>  4k           | 194 MB/s | 366 MB/s | 626 MB/s | 1.0 GB/s | 1.4 GB/s
>>  8k (bigalloc)| 188 MB/s | 359 MB/s | 612 MB/s | 996 MB/s | 1.4 GB/s
>>  16k(bigalloc)| 208 MB/s | 378 MB/s | 642 MB/s | 1.0 GB/s | 1.4 GB/s
>>  32k(bigalloc)| 184 MB/s | 368 MB/s | 637 MB/s | 995 MB/s | 1.4 GB/s
>>  64k(bigalloc)| 208 MB/s | 389 MB/s | 634 MB/s | 1.0 GB/s | 1.4 GB/s
>>
>> Patched(PAGE_SIZE=4096):
>>
>>    BIO   | bs=4k    | bs=8k    | bs=16k   | bs=32k   | bs=64k
>> ---------|----------|----------|----------|----------|------------
>>  4k      | 1.5 GB/s | 2.1 GB/s | 2.8 GB/s | 3.4 GB/s | 3.8 GB/s
>>  8k (LBS)| 1.7 GB/s | 2.3 GB/s | 3.2 GB/s | 4.2 GB/s | 4.7 GB/s
>>  16k(LBS)| 2.0 GB/s | 2.7 GB/s | 3.6 GB/s | 4.7 GB/s | 5.4 GB/s
>>  32k(LBS)| 2.2 GB/s | 3.1 GB/s | 3.9 GB/s | 4.9 GB/s | 5.7 GB/s
>>  64k(LBS)| 2.4 GB/s | 3.3 GB/s | 4.2 GB/s | 5.1 GB/s | 6.0 GB/s
>>
>>    DIO   | bs=4k    | bs=8k    | bs=16k   | bs=32k   | bs=64k
>> ---------|----------|----------|----------|----------|------------
>>  4k      | 204 MB/s | 355 MB/s | 627 MB/s | 1.0 GB/s | 1.4 GB/s
>>  8k (LBS)| 210 MB/s | 356 MB/s | 602 MB/s | 997 MB/s | 1.4 GB/s
>>  16k(LBS)| 191 MB/s | 361 MB/s | 589 MB/s | 981 MB/s | 1.4 GB/s
>>  32k(LBS)| 181 MB/s | 330 MB/s | 581 MB/s | 951 MB/s | 1.3 GB/s
>>  64k(LBS)| 148 MB/s | 272 MB/s | 499 MB/s | 840 MB/s | 1.3 GB/s
>>
>>
>> The results show:
>>
>>  * The code changes have almost no impact on the original 4k write
>>    performance of ext4.
>>  * Compared with bigalloc, LBS improves BIO write performance by about 50%
>>    on average.
>>  * Compared with bigalloc, LBS shows degradation in DIO write performance,
>>    which increases as the filesystem block size grows and the test bs
>>    decreases, with a maximum degradation of about 30%.
>>
>> The DIO regression is primarily due to the increased time spent in
>> crc32c_arch() within ext4_block_bitmap_csum_set() during block allocation,
>> as the block size grows larger. This indicates that larger filesystem block
>> sizes are not always better; please choose an appropriate block size based
>> on your I/O workload characteristics.
>>
>> We are also planning further optimizations for block allocation under LBS
>> in the future.
>>
>> Comments and questions are, as always, welcome.
>>
>> Thanks,
>> Baokun
> Hi Baokun,
>
> I've gone throught the series and the changes look mostly straight
> forward to me. I've started running some regression tests on my PowerPC
> machine. It's 64k pgsz so I can only test upto bs == ps, but everything
> looks normal for now. I'll report here if there are any regressions.
>
> Regardless, feel free to add:
> Reviewed-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>

Thank you for your review and testing!


Cheers,
Baokun