From: Baokun Li <libaokun1@huawei.com>
To: Jan Kara <jack@suse.cz>
Cc: <linux-ext4@vger.kernel.org>, <tytso@mit.edu>,
<adilger.kernel@dilger.ca>, <linux-kernel@vger.kernel.org>,
<kernel@pankajraghav.com>, <mcgrof@kernel.org>,
<linux-fsdevel@vger.kernel.org>, <linux-mm@kvack.org>,
<yi.zhang@huawei.com>, <yangerkun@huawei.com>,
<chengzhihao1@huawei.com>, <libaokun1@huawei.com>,
Baokun Li <libaokun@huaweicloud.com>
Subject: Re: [PATCH 21/25] ext4: make online defragmentation support large block size
Date: Wed, 5 Nov 2025 19:28:00 +0800 [thread overview]
Message-ID: <adbcac4d-e1fc-47a0-ad36-4672ff3c71f5@huawei.com> (raw)
In-Reply-To: <vkbarfyd6ozrrljhvwhmy2cq23mby6mxl2kxlsxp2wqgmvxvgi@6sgmqhhdnmru>
On 2025-11-05 17:50, Jan Kara wrote:
> On Sat 25-10-25 11:22:17, libaokun@huaweicloud.com wrote:
>> From: Zhihao Cheng <chengzhihao1@huawei.com>
>>
>> There are several places assuming that block size <= PAGE_SIZE, modify
>> them to support large block size (bs > ps).
>>
>> Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
>> Signed-off-by: Baokun Li <libaokun1@huawei.com>
> ...
>
>> @@ -565,7 +564,7 @@ ext4_move_extents(struct file *o_filp, struct file *d_filp, __u64 orig_blk,
>> struct inode *orig_inode = file_inode(o_filp);
>> struct inode *donor_inode = file_inode(d_filp);
>> struct ext4_ext_path *path = NULL;
>> - int blocks_per_page = PAGE_SIZE >> orig_inode->i_blkbits;
>> + int blocks_per_page = 1;
>> ext4_lblk_t o_end, o_start = orig_blk;
>> ext4_lblk_t d_start = donor_blk;
>> int ret;
>> @@ -608,6 +607,9 @@ ext4_move_extents(struct file *o_filp, struct file *d_filp, __u64 orig_blk,
>> return -EOPNOTSUPP;
>> }
>>
>> + if (i_blocksize(orig_inode) < PAGE_SIZE)
>> + blocks_per_page = PAGE_SIZE >> orig_inode->i_blkbits;
>> +
> I think these are strange and the only reason for this is that
> ext4_move_extents() tries to make life easier to move_extent_per_page() and
> that doesn't really work with larger folios anymore. I think
> ext4_move_extents() just shouldn't care about pages / folios at all and
> pass 'cur_len' as the length to the end of extent / moved range and
> move_extent_per_page() will trim the length based on the folios it has got.
>
> Also then we can rename some of the variables and functions from 'page' to
> 'folio'.
Yes, the code here doesn’t really support folios. YI mentioned earlier
that he would make online defragmentation support large folios. So in
this patch I only avoided shifting negative values, without doing a
deeper conversion.
YI’s conversion work looks nearly complete, so in the next version I will
rebase on top of his patches. Since his patch already removes the
function modified here, the next version will likely drop this patch or
adapt it accordingly.
Thanks for your review!
Cheers,
Baokun
>> /* Protect orig and donor inodes against a truncate */
>> lock_two_nondirectories(orig_inode, donor_inode);
>>
>> @@ -665,10 +667,8 @@ ext4_move_extents(struct file *o_filp, struct file *d_filp, __u64 orig_blk,
>> if (o_end - o_start < cur_len)
>> cur_len = o_end - o_start;
>>
>> - orig_page_index = o_start >> (PAGE_SHIFT -
>> - orig_inode->i_blkbits);
>> - donor_page_index = d_start >> (PAGE_SHIFT -
>> - donor_inode->i_blkbits);
>> + orig_page_index = EXT4_LBLK_TO_P(orig_inode, o_start);
>> + donor_page_index = EXT4_LBLK_TO_P(donor_inode, d_start);
>> offset_in_page = o_start % blocks_per_page;
>> if (cur_len > blocks_per_page - offset_in_page)
>> cur_len = blocks_per_page - offset_in_page;
>> --
>> 2.46.1
>>
next prev parent reply other threads:[~2025-11-05 11:28 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-25 3:21 [PATCH 00/25] ext4: enable block size larger than page size libaokun
2025-10-25 3:21 ` [PATCH 01/25] ext4: remove page offset calculation in ext4_block_zero_page_range() libaokun
2025-11-03 7:41 ` Jan Kara
2025-10-25 3:21 ` [PATCH 02/25] ext4: remove page offset calculation in ext4_block_truncate_page() libaokun
2025-11-03 7:42 ` Jan Kara
2025-10-25 3:21 ` [PATCH 03/25] ext4: remove PAGE_SIZE checks for rec_len conversion libaokun
2025-11-03 7:43 ` Jan Kara
2025-10-25 3:22 ` [PATCH 04/25] ext4: make ext4_punch_hole() support large block size libaokun
2025-11-03 8:05 ` Jan Kara
2025-11-04 6:55 ` Baokun Li
2025-10-25 3:22 ` [PATCH 05/25] ext4: enable DIOREAD_NOLOCK by default for BS > PS as well libaokun
2025-11-03 8:06 ` Jan Kara
2025-10-25 3:22 ` [PATCH 06/25] ext4: introduce s_min_folio_order for future BS > PS support libaokun
2025-11-03 8:19 ` Jan Kara
2025-10-25 3:22 ` [PATCH 07/25] ext4: support large block size in ext4_calculate_overhead() libaokun
2025-11-03 8:14 ` Jan Kara
2025-11-03 14:37 ` Baokun Li
2025-10-25 3:22 ` [PATCH 08/25] ext4: support large block size in ext4_readdir() libaokun
2025-11-03 8:27 ` Jan Kara
2025-10-25 3:22 ` [PATCH 09/25] ext4: add EXT4_LBLK_TO_B macro for logical block to bytes conversion libaokun
2025-11-03 8:21 ` Jan Kara
2025-10-25 3:22 ` [PATCH 10/25] ext4: add EXT4_LBLK_TO_P and EXT4_P_TO_LBLK for block/page conversion libaokun
2025-11-03 8:26 ` Jan Kara
2025-11-03 14:45 ` Baokun Li
2025-11-05 8:27 ` Jan Kara
2025-10-25 3:22 ` [PATCH 11/25] ext4: support large block size in ext4_mb_load_buddy_gfp() libaokun
2025-11-05 8:46 ` Jan Kara
2025-10-25 3:22 ` [PATCH 12/25] ext4: support large block size in ext4_mb_get_buddy_page_lock() libaokun
2025-11-05 9:13 ` Jan Kara
2025-11-05 9:44 ` Baokun Li
2025-10-25 3:22 ` [PATCH 13/25] ext4: support large block size in ext4_mb_init_cache() libaokun
2025-11-05 9:18 ` Jan Kara
2025-10-25 3:22 ` [PATCH 14/25] ext4: prepare buddy cache inode for BS > PS with large folios libaokun
2025-11-05 9:19 ` Jan Kara
2025-10-25 3:22 ` [PATCH 15/25] ext4: rename 'page' references to 'folio' in multi-block allocator libaokun
2025-11-05 9:21 ` Jan Kara
2025-10-25 3:22 ` [PATCH 16/25] ext4: support large block size in ext4_mpage_readpages() libaokun
2025-11-05 9:26 ` Jan Kara
2025-10-25 3:22 ` [PATCH 17/25] ext4: support large block size in ext4_block_write_begin() libaokun
2025-11-05 9:28 ` Jan Kara
2025-10-25 3:22 ` [PATCH 18/25] ext4: support large block size in mpage_map_and_submit_buffers() libaokun
2025-11-05 9:30 ` Jan Kara
2025-10-25 3:22 ` [PATCH 19/25] ext4: support large block size in mpage_prepare_extent_to_map() libaokun
2025-11-05 9:31 ` Jan Kara
2025-10-25 3:22 ` [PATCH 20/25] ext4: support large block size in __ext4_block_zero_page_range() libaokun
2025-11-05 9:33 ` Jan Kara
2025-10-25 3:22 ` [PATCH 21/25] ext4: make online defragmentation support large block size libaokun
2025-11-05 9:50 ` Jan Kara
2025-11-05 10:48 ` Zhang Yi
2025-11-05 11:28 ` Baokun Li [this message]
2025-10-25 3:22 ` [PATCH 22/25] fs/buffer: prevent WARN_ON in __alloc_pages_slowpath() when BS > PS libaokun
2025-10-25 4:45 ` Matthew Wilcox
2025-10-25 5:13 ` Darrick J. Wong
2025-10-25 6:32 ` Baokun Li
2025-10-25 7:01 ` Zhang Yi
2025-10-25 17:56 ` Matthew Wilcox
2025-10-27 2:57 ` Baokun Li
2025-10-27 7:40 ` Christoph Hellwig
2025-10-30 21:25 ` Matthew Wilcox
2025-10-31 1:47 ` Zhang Yi
2025-10-31 1:55 ` Baokun Li
2025-10-25 6:34 ` Baokun Li
2025-10-25 3:22 ` [PATCH 23/25] jbd2: " libaokun
2025-10-25 3:22 ` [PATCH 24/25] ext4: add checks for large folio incompatibilities " libaokun
2025-11-05 9:59 ` Jan Kara
2025-10-25 3:22 ` [PATCH 25/25] ext4: enable block size larger than page size libaokun
2025-11-05 10:14 ` Jan Kara
2025-11-06 2:44 ` Baokun Li
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=adbcac4d-e1fc-47a0-ad36-4672ff3c71f5@huawei.com \
--to=libaokun1@huawei.com \
--cc=adilger.kernel@dilger.ca \
--cc=chengzhihao1@huawei.com \
--cc=jack@suse.cz \
--cc=kernel@pankajraghav.com \
--cc=libaokun@huaweicloud.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mcgrof@kernel.org \
--cc=tytso@mit.edu \
--cc=yangerkun@huawei.com \
--cc=yi.zhang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox