Can't resize2fs - combination of flex_bg and !resize_inode

Question

I recently set up my first software raid with mdadm and after adding more disks to the raid I am unable to resize the filesystem to the full size of the raid. I created a single (~16TB) filesystem on /dev/md0 via:

mkfs.ext4 -v -b 4096 -t huge -E stride=128,stripe-width=256 /dev/md0

I then waited painfully for a couple of days as all of the data from the old raid copied over to the new raid; I moved over the disks and grew the raid and then finally I:

resize2fs -p /dev/md0

Which informs me that

resize2fs 1.42 (29-Nov-2011)
resize2fs: /dev/md0: The combination of flex_bg and !resize_inode features is not supported by resize2fs

I lack any understanding of exactly what these two features are for or why the combination is troublesome, so against my better judgement I tried to add resize_inode:

tune2fs -O +resize_inode /dev/md0

But I got shot down:

Setting filesystem feature 'resize_inode' not supported.

And I'm not brave enough to try to remove flex_bg as I really don't want to do anything that might put my data at risk. I'm running Ubuntu 12.04 with the 3.5.1 kernel:

Linux critter 3.5.1-030501-generic #201208091310 SMP Thu Aug 9 17:11:48 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

I tested resize2fs again with v1.42.5 (the latest available release) to no avail. So, to be clear, my question is: how can I resize this ext4 filesystem to the size of the raid (without recreating it, preferably)?

Edit: here's some filesystem information that might be helpful.

tune2fs -l /dev/md0
tune2fs 1.42 (29-Nov-2011)
Filesystem volume name:   <none>
Last mounted on:          /media/Bigger
Filesystem UUID:          baecfa03-74c1-42ad-8e19-3b823f05f502
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              274700288
Block count:              4395202560
Reserved block count:     219760128
Free blocks:              247712956
Free inodes:              274636266
First block:              0
Block size:               4096
Fragment size:            4096
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         2048
Inode blocks per group:   128
RAID stride:              128
RAID stripe width:        768
Flex block group size:    16
Filesystem created:       Fri Aug 17 02:54:50 2012
Last mount time:          Mon Aug 20 02:21:51 2012
Last write time:          Mon Aug 20 02:25:07 2012
Mount count:              3
Maximum mount count:      -1
Last checked:             Fri Aug 17 02:54:50 2012
Check interval:           0 (<none>)
Lifetime writes:          16 TB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      b357ba49-60b1-4c55-837f-a70c8285a8f5
Journal backup:           inode blocks

Answer 1

This might help you -- http://www.spinics.net/lists/linux-ext4/msg27511.html

Take backups before you do anything since what you are doing seems very risky with ext4.

See this -- https://ext4.wiki.kernel.org/index.php/Ext4_Howto

WARNING: It is NOT recommended to resize the inodes using resize2fs with 
e2fsprogs 1.41.0 or later, as this is known to corrupt some filesystems. 

Upto 16TB seems doable with a 64bit ext4 file system but the state of the tools seem to be in a flux. This is a very good read -- http://blog.ronnyegner-consulting.de/2011/08/18/ext4-and-the-16-tb-limit-now-solved/

Unless you hear from a ext4 file system developer here, you may want to ask this question on the ext4 mailing lists.

Answer 2

Chida - I had previously found those same URLs, but I knew from experience that ext4 would handle more than 16TB with an up-to-date kernel and tools. But it still wasn't working.

Finally, I got an answer from the linux-ext4 mailing list - the mkfs.ext4 command I used was borked. I mixed up -t and -T. It should have read:

mkfs.ext4 -v -b 4096 -t ext4 -T huge -E stride=128,stripe-width=256 /dev/md0

And then - I am told - it would have included resize_inode and worked as expected.

Thanks for your help.

Answer 3

I know this is an old one, but just for the sake of someone reading this in the future...

Theflex_bg is (relatively new) a feature that allows the filesystem to divide itself more flexibly into the "block groups". Traditionally it is divided to block groups with equal, predefined sizes. The advantage of flex_bg is is that a bigger virtual block group will allow having for example a bigger inode table crowded together - and then writing lot's of files could happen faster as it wouldn't need to go look for space in another block group.

The resize_inode is a space pre-allocated for the case where you might want to resize the filesystem in the future. It is mainly used to try to prevent the need of moving the inode table physically.

The resize_inode takes some space and allow for smoother and faster resizing of a filesystem, and flex_bg takes down inode count (file/dir count) constraints and improves performance.

The sad thing is that mkfs was probably not potent enough to be able to change these feature on a filesystem by the time the question was posted, and may still have trouble doing so for some features. But changing those should not hurt your filesystem, as long as it is healthy. So always run fsck -f /dev/SD... before trying to change such features, and then you are good to go.