| Message ID | AANLkTin-q=dOHRh2TB9PtUyvB2YcbLTz+en_aTp+voVU@mail.gmail.com |
|---|---|
| State | New, archived |
| Headers | show |
diff --git a/misc/mke2fs.c b/misc/mke2fs.c index add7c0c..b1a6d62 100644 --- a/misc/mke2fs.c +++ b/misc/mke2fs.c @@ -722,6 +722,8 @@ static void parse_extended_opts(struct ext2_super_block *param, bpg = param->s_blocks_per_group; if (!bpg) bpg = blocksize * 8; + if (!param->s_desc_size && (param->s_feature_incompat & EXT4_FEATURE_INCOMPAT_64BIT)) + param->s_desc_size = EXT2_MIN_DESC_SIZE_64BIT; gdpb = EXT2_DESC_PER_BLOCK(param);
Is there any way to allow for a larger online resize with ext4? On x86 hardware (4kb block size), it looks to me like the current limitation is up to 16TB for regular 32-bit filesystems (which isn't an issue), but only 8TB additional for filesystems with the 64bit flag set. Is there any chance that can/will be improved? Also, while I was trying this out, I ran into a divide by zero error when running mke2fs with the 64bit flag enabled, and the resize= extended option set. This is because EXT2_DESC_PER_BLOCK() tries to use s_desc_size if the 64bit flag is set, which isn't set at that time. This diff against master works around it, but perhaps there's a more appropriate way? Should EXT2_DESC_PER_BLOCK() make sure that the s_desc_size != 0? group_desc_count = (__u32) ext2fs_div64_ceil( ext2fs_blocks_count(param), bpg); -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html