去年我设置了一个软件 RAID5，其中 5x3TB 产生 12TB 可用容量。就在今天，需要更多存储空间，我已将 RAID 扩展到另外两个 3TB 磁盘：
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid5 sdd1[7] sde1[6] sdb1[4] sda1[5] sdc1[2] sdg1[1] sdf1[0]
17580801024 blocks super 1.2 level 5, 512k chunk, algorithm 2 [7/7] [UUUUUUU]
unused devices: <none>
这意味着我现在应该有大约 6x3TB = 18TB 可用/dev/md0。resize2fs，调用时没有大小参数，现在告诉我新的大小在 32 位模式下是不可能的。 一些研究表明，这是一个常见问题，如果不进行大量修改就很难解决，而我不愿意这样做。
tune2fs确认64bit-flag 确实丢失了 :-( 尽管在配置文件中auto_64-bit_support = 1设置了（并且在创建文件系统时也应该设置）。但事后抱怨无法改变的事情是没有用的。
遗憾的是，无法进行完整备份和恢复（我知道，应该存在备份全部但资金只够备份真的的重要组成部分）。
然后我尝试将文件系统的大小调整为 16TB，resize2fs -S 128 /dev/md0 16T这似乎可行，但返回错误，告诉我设备上没有足够的空间并建议我运行e2fsck -fy /dev/md0- 奇怪的事情。我的心跳得像疯了一样，直到检查结果正常！不过，告诉它调整大小是可行的15T。
我认为我们还能再用几个月的 15TB，但有大约 3TB 闲置不用，这实在是太让我讨厌了。我现在的问题是，我该如何利用这 3TB。我的研究方向是
- 转换为 btrfs，它似乎支持大于 16TB 的文件系统，并且无需备份/恢复周期 - 但不同的消息来源表示这并不可靠，不应该在生产中使用。
- 在剩余的 3TB 上进行分区
/dev/md0以创建第二个文件系统 - 似乎是不可能的（分区表类型loop） - 设置 LVM - 无需重新格式化是否可行？
但这些“解决方案”都没有经过充分的记录/测试，或者如上所述不是一个选项，所以我现在只能使用/dev/md018TB 的 ext4 文件系统，只有 15TB 和 3TB 的可用空间。有人知道我还可以尝试/做/考虑什么吗？
答案1
我在 CentOS 6 机器上遇到了完全相同的问题。我的内核支持 64 位，但文件系统最初不是使用 64 位标志集格式化的。不支持 >16TB。:-( 我可以确认 tune2fs 在这里没有帮助。您无法将 ext2/3/4 文件系统转换为 64 位。
不过我很幸运，因为我在 MD 阵列上使用 LVM，所以我开始以一种有点迂回的方式向阵列添加空间，即使用 MD 阵列中的剩余空间创建另一个 LV，并使用 64 位选项对其进行格式化。然后，我将一些数据从旧文件系统移动到新文件系统，然后缩小旧文件系统，重新调整（缩小旧文件系统，增加新文件系统）LVM 卷组的大小，增加 64 位文件系统，然后重复（多次）。这不是理想的选择，但我的建议是重新对 md 阵列进行分区并按此方式进行。这是可能的。（GParted 在这里会非常有用）
为了解决您的研究方向，根据我的系统管理员经验：
转换为 BTRFS 可能不是一个选择。正如文档所示，BTRFS 仍在开发中（即使是内核 3.1 中包含的 3.12），不应用于存储关键（而非备份）数据。虽然没有任何迹象表明您的文件系统会自发损坏，但它比使用 ext4 稍微危险一些。
分区是必经之路，使用 GParted 等工具可以简化很多。在 LVM 上甚至更加简单...
你能安装 LVM，然后你就可以尝试第三方工具区块将您的 md 阵列（块设备）转换为 LVM 卷和存储组。这将使重新分区和调整大小变得更容易一些。虽然您不需要转换根文件系统，但该工具可能有助于将 LVM 纳入其中。如果出现问题，我宁愿不走这条路。我会事先在测试台上练习一下。
也许只需使用 GParted 重新分区（并使用 mkfs.ext4 -O 64bit .... 手动格式化新分区）并手动移动数据即可。检查以确保所有文件的大小均小于 3TB，否则您还需要混合使用外部存储。