我最近用 mdadm 设置了我的第一个软件 raid，在向 raid 添加更多磁盘后，我无法将文件系统的大小调整为 raid 的完整大小。我通过以下方式在 /dev/md0 上创建了一个（~16TB）文件系统：
mkfs.ext4 -v -b 4096 -t huge -E stride=128,stripe-width=256 /dev/md0
然后我痛苦地等待了几天，因为所有数据从旧 raid 复制到了新 raid；我移动了磁盘并扩大了 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
我不太明白这两个功能到底有什么用处，也不太明白为什么这种组合会带来麻烦，所以违背自己的判断，我尝试添加 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（最新可用版本）测试了 resize2fs，但无济于事。因此，明确地说，我的问题是：如何将此 ext4 文件系统调整为 raid 的大小（最好不重新创建它）？
编辑：这里有一些可能有用的文件系统信息。
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
答案1
这可能会帮助你——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.
使用 64 位 ext4 文件系统似乎可以实现高达 16TB 的容量，但工具的状态似乎在不断变化。这是一篇非常好的文章——http://blog.ronnyegner-consulting.de/2011/08/18/ext4-and-the-16-tb-limit-now-solved/
除非您在这里听到 ext4 文件系统开发人员的消息，否则您可能想在 ext4 邮件列表中询问这个问题。
答案2
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 并按预期工作。
感谢您的帮助。
答案3
我知道这是一个老问题，但只是为了将来有人能读到它......
这flex_bg是一项（相对较新的）功能，允许文件系统更灵活地将自身划分为“块组”。传统上，它会被划分为具有相等、预定义大小的块组。它的优点flex_bg是，更大的虚拟块组将允许将更大的 inode 表挤在一起 - 然后可以更快地写入大量文件，因为它不需要在另一个块组中寻找空间。
这resize_inode是预先分配的空间，用于将来可能需要调整文件系统大小的情况。它主要用于尝试以避免需要物理移动 inode 表。
它resize_inode占用一些空间并允许更平滑、更快地调整文件系统大小，并flex_bg减少 inode 计数（文件/目录计数）限制并提高性能。
遗憾的是，在问题发布时，mkfs 可能还不够强大，无法在文件系统上更改这些功能，并且对于某些功能可能仍然有困难。但更改这些不应该损坏你的文件系统，只要它是健康的。所以总是在尝试更改这些功能之前运行fsck -f /dev/SD...，然后就可以开始了。