我最近用mdadm设置了我的第一个软件raid，在向raid添加更多的磁盘之后，我无法将文件系统重新设置为raid的全部大小。 我通过以下方法在/ dev / md0上创build了一个（〜16TB）文件系统：
mkfs.ext4 -v -b 4096 -t huge -E stride=128,stripe-width=256 /dev/md0 然后我等了几天，因为老袭击的所有数据都抄袭了新的袭击。 我移动了磁盘，并增加了RAID，最后我：
resize2fs -p /dev/md0
哪一个通知我
resize2fs 1.42 (29-Nov-2011) resize2fs: /dev/md0: The combination of flex_bg and !resize_inode features is not supported by resize2fs
我完全不了解这两个function究竟是为了什么，或者为什么这个组合很麻烦，所以为了更好的判断，我尝试添加resize_inode：
tune2fs -O +resize_inode /dev/md0
但是我被击落了：
Setting filesystem feature 'resize_inode' not supported.
而且我还不够勇于去除flex_bg，因为我真的不想做任何可能使我的数据处于危险之中的事情。 我正在使用3.5.1内核运行Ubuntu 12.04：
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
我用v1.42.5（最新的可用版本）再次testingresize2fs无济于事。 所以，为了清楚起见，我的问题是：我怎样才能调整这个ext4文件系统的大小突袭（不重新创build，最好）？
编辑：这里有一些文件系统的信息，可能会有所帮助。
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
这可能会帮助你 – http://www.spinics.net/lists/linux-ext4/msg27511.html
做任何事之前做备份，因为你正在做的事情似乎非常冒险的ext4。
看到这个 – 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似乎可以用64位的ext4文件系统来实现，但是工具的状态似乎在变化中。 这是一个很好的阅读 – http://blog.ronnyegner-consulting.de/2011/08/18/ext4-and-the-16-tb-limit-now-solved/
除非你在这里听到一个ext4文件系统的开发者，否则你可能想在ext4邮件列表中提出这个问题。
Chida – 之前我曾经发现过那些相同的URL，但是我从经验中知道，ext4将会使用最新的内核和工具来处理超过16TB的内容。 但它仍然没有工作。
最后，我从linux-ext4邮件列表中得到了答案 – 我使用的mkfs.ext4命令是borked。 我混合了-t和-T。 它应该读取：
mkfs.ext4 -v -b 4096 -t ext4 -T huge -E stride=128,stripe-width=256 /dev/md0
然后 – 我被告知 – 这将包括resize_inode和按预期工作。
谢谢你的帮助。
我知道这是一个旧的，但只是为了将来有人读这个…
flex_bg是一个（相对较新的）function，允许文件系统更灵活地将其划分为“块组”。 传统上，它被分割为具有相同的预定义大小的组。 flex_bg的优点是，一个更大的虚拟块组将允许拥有一个更大的inode表拥挤在一起 – 然后写很多的文件可以更快地发生，因为它不需要去寻找另一个块组中的空间。
resize_inode是预先分配的空间，您可能希望将来调整文件系统的大小。 主要用于防止物理移动inode表的需要。
resize_inode占用一些空间，并允许更平滑和更快速地调整文件系统的大小， flex_bg降低inode计数（文件/目录计数）约束并提高性能。
可悲的是，mkfs可能没有足够强大的function，可以在发布问题时在文件系统上更改这些function，而对于某些function，这样做可能仍然有困难。 但改变这些不应该伤害你的文件系统，只要它是健康的。 所以在尝试改变这些function之前， 总是运行fsck -f /dev/SD... ，然后就可以开始了。