Message ID | 20230629120044.1261968-9-shikemeng@huaweicloud.com |
---|---|
State | Superseded |
Headers | show |
Series | fixes and cleanups to ext4 resize | expand |
On Thu, Jun 29, 2023 at 08:00:39PM +0800, Kemeng Shi wrote: > We treat free_clusters_count in cluster unit while free_blocks_count is > in block unit. Convert free_blocks_count to cluster unit to match the > unit. > Currently, verify_group_input is only called from ext4_ioctl_group_add > which does not support bigalloc yet. The dismatch is easily ingored > when we try to support bigalloc in ext4_ioctl_group_add (ext4_resize_fs > already supports resize with bigalloc enabled). Just fix this in > advance. > > Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com> I'd rewrite the commit description a bit: The field free_cluster_count in struct ext4_new_group_data should be in units of clusters. In verify_group_input() this field is being filled in units of blocks. Fortunately, we don't support online resizing of bigalloc file systems, and for non-bigalloc file systems, the cluster size == block size. But fix this in case we do support online resizing of bigalloc file systems in the future. Other than that: Reviewed-by: Theodore Ts'o <tytso@mit.edu> - Ted
on 8/16/2023 11:22 AM, Theodore Ts'o wrote: > On Thu, Jun 29, 2023 at 08:00:39PM +0800, Kemeng Shi wrote: >> We treat free_clusters_count in cluster unit while free_blocks_count is >> in block unit. Convert free_blocks_count to cluster unit to match the >> unit. >> Currently, verify_group_input is only called from ext4_ioctl_group_add >> which does not support bigalloc yet. The dismatch is easily ingored >> when we try to support bigalloc in ext4_ioctl_group_add (ext4_resize_fs >> already supports resize with bigalloc enabled). Just fix this in >> advance. >> >> Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com> > > I'd rewrite the commit description a bit: > > The field free_cluster_count in struct ext4_new_group_data should be > in units of clusters. In verify_group_input() this field is being > filled in units of blocks. Fortunately, we don't support online > resizing of bigalloc file systems, and for non-bigalloc file systems, > the cluster size == block size. But fix this in case we do support > online resizing of bigalloc file systems in the future. > Sorry for my poor language and thanks a lot for the rewrite. I will fill rewriten description in next version! > Other than that: > > Reviewed-by: Theodore Ts'o <tytso@mit.edu> > > - Ted >
diff --git a/fs/ext4/resize.c b/fs/ext4/resize.c index 07828903b818..c532bb613043 100644 --- a/fs/ext4/resize.c +++ b/fs/ext4/resize.c @@ -154,8 +154,9 @@ static int verify_group_input(struct super_block *sb, overhead = ext4_group_overhead_blocks(sb, group); metaend = start + overhead; - input->free_clusters_count = free_blocks_count = - input->blocks_count - 2 - overhead - sbi->s_itb_per_group; + free_blocks_count = input->blocks_count - 2 - overhead - + sbi->s_itb_per_group; + input->free_clusters_count = EXT4_B2C(sbi, free_blocks_count); if (test_opt(sb, DEBUG)) printk(KERN_DEBUG "EXT4-fs: adding %s group %u: %u blocks "
We treat free_clusters_count in cluster unit while free_blocks_count is in block unit. Convert free_blocks_count to cluster unit to match the unit. Currently, verify_group_input is only called from ext4_ioctl_group_add which does not support bigalloc yet. The dismatch is easily ingored when we try to support bigalloc in ext4_ioctl_group_add (ext4_resize_fs already supports resize with bigalloc enabled). Just fix this in advance. Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com> --- fs/ext4/resize.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)