☰

有没有人成功将 Centos 7.x 上的文件系统调整到 16TB 以上

tag-icon • tag-icon linux storage
有没有人成功将 Centos 7.x 上的文件系统调整到 16TB 以上

我有一台 Centos 6.5 服务器连接到存储阵列。它从阵列中挂载了一个 16TB 的卷。如果我将阵列上的卷大小调整为 45TB，则无法扩展文件系统以使用该空间。显然，Centos 7.x 已认证最大可达 50TB 的文件系统。有没有人成功将 7.x 上的现有文件系统调整为 16TB 以上？

[root@init105-12 hariharan]# lsblk /dev/mapper/3624a93708a6e42d13a7d45ae0001101f
NAME                                     MAJ:MIN RM SIZE RO TYPE  MOUNTPOINT
3624a93708a6e42d13a7d45ae0001101f (dm-2) 253:2    0  45T  0 mpath
[root@init105-12 hariharan]#
[root@init105-12 hariharan]# resize2fs /dev/mapper/3624a93708a6e42d13a7d45ae0001101f
resize2fs 1.41.12 (17-May-2010)
resize2fs: New size too large to be expressed in 32 bits

答案1

ext4 的限制是 16 TiB，所以你不能
https://access.redhat.com/solutions/1532

如果它是生产环境，您就有工作要做......

尝试在具有 XFS 文件系统的测试环境中构建相同的服务器

答案2

背景：当这个问题出现时，人们经常对 64 位操作系统或“64 位文件系统”一词感到困惑。我们谈论的是 ext4 文件系统中的 inode 表。ext4 中的默认块大小为 4k，块使用 32 位 inode 表寻址，这意味着文件系统的可寻址字节数限制为 2^32 * 4k，即 16TiB。长期以来，Linux 内核中的 ext4 支持一直支持 64 位 inode 表（使用 4k 块最大可达 1EiB），但 CentOS 6 和 7 附带的 e2fs 工具不支持此功能。如果“RedHat 认证”测试对您有意义，则不支持 64 位 inode 表，但问题是针对 CentOS 提出的，所以让我们继续。

免责声明：我已通过更新 e2fs 工具在 CentOS 6 和 7 以及较旧的 Ubuntu 上为大于 16TiB 的 ext4 文件系统启用了 64 位 inode 表，因此我可以告诉您这确实有效，但当然，您应该在尝试此操作之前备份数据。此过程涉及编译操作系统级工具，因此不适合胆小者。此外，我读到 GRUB 不支持 64 位 inode 表，因此不要对您的启动分区（或根文件系统，如果您将 /boot 保留在那里，但这不是 CentOS 6 或 7 自行安装的方式）执行此操作。您已收到警告。

下载 e2fsprogs 版本 1.43.9 并构建它。有较新的版本可用，但此版本在 CentOS 6 和 7 上均可顺利构建，并支持我们需要的所有功能，而较新的代码使用 CentOS 6 附带的 gcc 版本不支持的功能。请注意，此过程需要 gcc，因此如果您不想在生产服务器上安装编译器，我建议在另一台具有相同 Linux 发行版的机器上构建，然后将构建的工具移动到您的生产环境中。首先，使用以下命令：

wget http://prdownloads.sourceforge.net/e2fsprogs/e2fsprogs-1.43.9.tar.gz
tar zxvf e2fsprogs-1.43.9.tar.gz
cd e2fsprogs-1.43.9
./configure
make

此时，如果您在要扩展分区的系统上，则可以以 root 身份运行“make install”（注意，前面的命令不应以 root/sudo 身份运行）。这将替换系统上现有的 e2fs 工具。如果您不想这样做，您可以简单地运行刚刚构建的二进制文件，我假设您接下来会这样做。让我们从检查相关文件系统开始。我将/dev/mapper/vg_data-lv_data在示例中使用命令，但您可能有/dev/sdb1或类似的东西作为目标。此命令以及在文件系统上运行的所有后续命令都需要 root 权限才能运行。

./misc/tune2fs -l /dev/mapper/vg_data-lv_data | grep "features"

此命令将列出所有已启用的文件系统功能。如果列表中有“64 位”，则说明您已完成操作，我不知道您为什么阅读此内容！在继续操作之前，您可能需要执行 e2fsck 并卸载文件系统。希望您知道如何卸载文件系统（这确实需要关闭文件系统中所有文件句柄）。要执行 fsck，命令如下：

./e2fsck/e2fsck -f /dev/mapper/vg_data-lv_data

如果文件系统已经很大，这可能需要一段时间。接下来，我们可以（最终）将 inode 表升级到 64 位：

./resize/resize2fs -b /dev/mapper/vg_data-lv_data

请注意，这不会调整文件系统的大小。您必须再次运行该命令（不带 -b 开关）才能进行实际调整大小。运行 resize 命令而不指定大小将自动使用所有可用空间，这通常是您想要执行的操作：

./resize/resize2fs /dev/mapper/vg_data-lv_data

您现在可以安装驱动器并享受额外的空间！您还可以tune2fs再次运行以检查文件系统功能列表是否现在显示了可爱的“64位”。

最后提示：如果您确实想在一个盒子上构建这些工具，然后将它们移动到生产服务器，最简单的方法是执行以下操作（不是以 root 身份）：

./configure --prefix=$HOME/local
tar zcvf e2fsprogs.tar.gz $HOME/local

然后将 e2fsprogs.tar.gz 复制到您的生产服务器。您将在 sbin 文件夹中找到构建的二进制文件。将它们放在您的生产服务器上后，您可以直接从提取它们的位置运行它们，也可以将提取到本地的文件夹移动到 /usr（以 root 身份）以替换操作系统附带的 e2fs 工具。

答案3

应该说清楚，问题是关于 64 位 Linux 上的 ext4。

是否可以考虑调整大小取决于：

  • 当前大小、新大小、FS 是否启用了 64 位功能
  • 如果当前大小和新大小均小于等于 16TB，则应该是安全的
  • 如果新大小 > 16TB 且 FS 已启用 64 位功能，则应该是安全的
  • 如果新大小 > 16TB，并且 FS 没有 64 位功能，则首先需要启用 64 位。您必须运行调整2fs大小-b启用它，然后进行实际调整大小。即使是 RHEL 7.x 附带的 resize2fs 也不接受 -b 选项。您必须从源代码构建 ext4 工具才能实现这一点。此外，Red Hat 显然不支持 -b。因此，在这种情况下调整大小似乎并不安全。

相关内容