Since auto_64-bit_support is on by default, resize_inode feature will
be disabled when creating a >16T ext4 according to mke2fs.conf(5).
This should also be done when making ext4 with "-O 64bit" to enable
64bit feature explicitly. Otherwise online resize to enlarge a
over-16T fs to larger would fail.
[root@localhost resize]# truncate -s 50t fs.img
[root@localhost resize]# losetup /dev/loop0 fs.img
[root@localhost resize]# mkfs -t ext4 -O 64bit /dev/loop0 30t
[root@localhost resize]# mount /dev/loop0 mnt
[root@localhost resize]# resize2fs /dev/loop0
resize2fs 1.42.7 (21-Jan-2013)
Filesystem at /dev/loop0 is mounted on /root/resize/mnt; on-line resizing required
old_desc_blocks = 3840, new_desc_blocks = 6400
resize2fs: Invalid argument While checking for on-line resizing support
And dmesg shows
[688378.442623] EXT4-fs (loop0): resizing filesystem from 6710886400 to 13421772800 blocks
[688378.443216] EXT4-fs warning (device loop0): verify_reserved_gdb:700: reserved GDT 3201 missing grp 177147 (5804756097)
[688378.443222] EXT4-fs (loop0): resized filesystem to 8858370048
[688378.528451] EXT4-fs warning (device loop0): ext4_group_extend:1710: can't shrink FS - resize aborted
With this fix resize2fs could do the online enlarge correctly.
Signed-off-by: Eryu Guan <[email protected]>
---
misc/mke2fs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/misc/mke2fs.c b/misc/mke2fs.c
index d96f156..e4102b9 100644
--- a/misc/mke2fs.c
+++ b/misc/mke2fs.c
@@ -1790,6 +1790,9 @@ profile_error:
fs_param.s_log_block_size = 2;
}
if ((fs_blocks_count > MAX_32_NUM) &&
+ (fs_param.s_feature_incompat & EXT4_FEATURE_INCOMPAT_64BIT))
+ fs_param.s_feature_compat &= ~EXT2_FEATURE_COMPAT_RESIZE_INODE;
+ if ((fs_blocks_count > MAX_32_NUM) &&
!(fs_param.s_feature_incompat & EXT4_FEATURE_INCOMPAT_64BIT) &&
get_bool_from_profile(fs_types, "auto_64-bit_support", 0)) {
fs_param.s_feature_incompat |= EXT4_FEATURE_INCOMPAT_64BIT;
--
1.8.3.1
On Thu, Jul 04, 2013 at 05:05:10PM +0800, Eryu Guan wrote:
> Since auto_64-bit_support is on by default, resize_inode feature will
> be disabled when creating a >16T ext4 according to mke2fs.conf(5).
>
> This should also be done when making ext4 with "-O 64bit" to enable
> 64bit feature explicitly. Otherwise online resize to enlarge a
> over-16T fs to larger would fail.
>
> [root@localhost resize]# truncate -s 50t fs.img
> [root@localhost resize]# losetup /dev/loop0 fs.img
> [root@localhost resize]# mkfs -t ext4 -O 64bit /dev/loop0 30t
> [root@localhost resize]# mount /dev/loop0 mnt
> [root@localhost resize]# resize2fs /dev/loop0
> resize2fs 1.42.7 (21-Jan-2013)
> Filesystem at /dev/loop0 is mounted on /root/resize/mnt; on-line resizing required
> old_desc_blocks = 3840, new_desc_blocks = 6400
> resize2fs: Invalid argument While checking for on-line resizing support
>
> And dmesg shows
> [688378.442623] EXT4-fs (loop0): resizing filesystem from 6710886400 to 13421772800 blocks
> [688378.443216] EXT4-fs warning (device loop0): verify_reserved_gdb:700: reserved GDT 3201 missing grp 177147 (5804756097)
> [688378.443222] EXT4-fs (loop0): resized filesystem to 8858370048
> [688378.528451] EXT4-fs warning (device loop0): ext4_group_extend:1710: can't shrink FS - resize aborted
>
> With this fix resize2fs could do the online enlarge correctly.
>
> Signed-off-by: Eryu Guan <[email protected]>
> ---
> misc/mke2fs.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/misc/mke2fs.c b/misc/mke2fs.c
> index d96f156..e4102b9 100644
> --- a/misc/mke2fs.c
> +++ b/misc/mke2fs.c
> @@ -1790,6 +1790,9 @@ profile_error:
> fs_param.s_log_block_size = 2;
> }
> if ((fs_blocks_count > MAX_32_NUM) &&
Do we really need to check it? My point is that we just clear
RESIZE_INODE flag if 64BIT flag is enabled.
- Zheng
> + (fs_param.s_feature_incompat & EXT4_FEATURE_INCOMPAT_64BIT))
> + fs_param.s_feature_compat &= ~EXT2_FEATURE_COMPAT_RESIZE_INODE;
> + if ((fs_blocks_count > MAX_32_NUM) &&
> !(fs_param.s_feature_incompat & EXT4_FEATURE_INCOMPAT_64BIT) &&
> get_bool_from_profile(fs_types, "auto_64-bit_support", 0)) {
> fs_param.s_feature_incompat |= EXT4_FEATURE_INCOMPAT_64BIT;
> --
> 1.8.3.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jul 05, 2013 at 09:21:28AM +0800, Zheng Liu wrote:
> Do we really need to check it? My point is that we just clear
> RESIZE_INODE flag if 64BIT flag is enabled.
It's better to use the resize_inode for file systems that are smaller
than 16TB, even if the 64-bit flag is enabled, since using the meta_bg
style resizing spreads out the block group descriptors, which
increases the time to mount the file system. Using the resize_inode
will defer the need to go to the meta_bg-style resizing until we cross
the 16TB boundary.
Cheers,
- Ted
On Sun, 7 Jul 2013, Theodore Ts'o wrote:
> Date: Sun, 7 Jul 2013 11:41:40 -0400
> From: Theodore Ts'o <[email protected]>
> To: Eryu Guan <[email protected]>, [email protected]
> Subject: Re: [PATCH] mke2fs: disable resize_inode feature if 64bit feature is
> enabled
Hi Ted,
are you going to take this in ?
Thanks!
-Lukas
>
> On Fri, Jul 05, 2013 at 09:21:28AM +0800, Zheng Liu wrote:
> > Do we really need to check it? My point is that we just clear
> > RESIZE_INODE flag if 64BIT flag is enabled.
>
> It's better to use the resize_inode for file systems that are smaller
> than 16TB, even if the 64-bit flag is enabled, since using the meta_bg
> style resizing spreads out the block group descriptors, which
> increases the time to mount the file system. Using the resize_inode
> will defer the need to go to the meta_bg-style resizing until we cross
> the 16TB boundary.
>
> Cheers,
>
> - Ted
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On Mon, Mar 03, 2014 at 04:40:21PM +0100, Lukáš Czerner wrote:
>
> are you going to take this in ?
>
> > It's better to use the resize_inode for file systems that are smaller
> > than 16TB, even if the 64-bit flag is enabled, since using the meta_bg
> > style resizing spreads out the block group descriptors, which
> > increases the time to mount the file system. Using the resize_inode
> > will defer the need to go to the meta_bg-style resizing until we cross
> > the 16TB boundary.
See my comments above.
If we create a file system which is say, 1T but with the 64-bit flag,
we do want the resize_inode feature to be used until we cross over the
32-bit boundary, because keeping block group descriptors contiguous
speeds up the mount time.
If I were to accept this patch, and/or Red Hat were to ship with it, I
will predict that you will get angry customer support calls about file
system mount times getting slow after doing a resize.
At some point what we may want to lazily load the block group
descriptors at mount time, to mitigate the slow mount time issue when
using meta_bg. We have a lot of assumptions in the code that the
block group descriptors are always available, though.
- Ted
On Tue, 4 Mar 2014, Theodore Ts'o wrote:
> Date: Tue, 4 Mar 2014 10:19:25 -0500
> From: Theodore Ts'o <[email protected]>
> To: Lukáš Czerner <[email protected]>
> Cc: Eryu Guan <[email protected]>, [email protected]
> Subject: Re: [PATCH] mke2fs: disable resize_inode feature if 64bit feature is
> enabled
>
> On Mon, Mar 03, 2014 at 04:40:21PM +0100, Lukáš Czerner wrote:
> >
> > are you going to take this in ?
> >
> > > It's better to use the resize_inode for file systems that are smaller
> > > than 16TB, even if the 64-bit flag is enabled, since using the meta_bg
> > > style resizing spreads out the block group descriptors, which
> > > increases the time to mount the file system. Using the resize_inode
> > > will defer the need to go to the meta_bg-style resizing until we cross
> > > the 16TB boundary.
>
> See my comments above.
>
> If we create a file system which is say, 1T but with the 64-bit flag,
> we do want the resize_inode feature to be used until we cross over the
> 32-bit boundary, because keeping block group descriptors contiguous
> speeds up the mount time.
>
> If I were to accept this patch, and/or Red Hat were to ship with it, I
> will predict that you will get angry customer support calls about file
> system mount times getting slow after doing a resize.
>
> At some point what we may want to lazily load the block group
> descriptors at mount time, to mitigate the slow mount time issue when
> using meta_bg. We have a lot of assumptions in the code that the
> block group descriptors are always available, though.
>
> - Ted
Hi Ted,
I am sorry, but am I missing something ? This patch seems to do
exactly that.
if ((fs_blocks_count > MAX_32_NUM) &&
+ (fs_param.s_feature_incompat & EXT4_FEATURE_INCOMPAT_64BIT))
+ fs_param.s_feature_compat &= ~EXT2_FEATURE_COMPAT_RESIZE_INODE;
The answer from you on that patch is commenting on a guestion from
Zheng Liu who is asking whether we could skip the MAX_32_NUM check.
So the patch seems to be ok for me.
Thanks!
-Lukas
On Thu, Mar 06, 2014 at 03:03:30PM +0100, Lukáš Czerner wrote:
>
> I am sorry, but am I missing something ? This patch seems to do
> exactly that.
>
> if ((fs_blocks_count > MAX_32_NUM) &&
> + (fs_param.s_feature_incompat & EXT4_FEATURE_INCOMPAT_64BIT))
> + fs_param.s_feature_compat &= ~EXT2_FEATURE_COMPAT_RESIZE_INODE;
>
> The answer from you on that patch is commenting on a guestion from
> Zheng Liu who is asking whether we could skip the MAX_32_NUM check.
You're right, I misread the patch and the e-mail thread.
Thanks, I've applied the patch.
- Ted