Can't resize2fs - combination of flex_bg and !resize_inode

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

Solution 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.

Solution 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.