如何将ext4分区的大小调整到超过16TB的限制？

26

尝试调整大小和不带64bit标志创建的旧ext4分区时，如果新大小等于或超过16TiB，则resize2fs 1.42将失败。

$ resize2fs -p /dev/mapper/target-device
resize2fs: New size too large to be expressed in 32 bits

我不想将文件复制到外部介质。我也不想冒险丢失数据。如何安全地调整音量大小？

ext4

— x
source

46

您正在尝试调整在该-O 64bit选项成为默认选项之前创建的文件系统的大小。可以将您的ext文件系统升级到64位地址，使其跨度更大（1024 PiB而不是16 TiB）。

假设您的目标设备称为/dev/mapper/target-device，这是您需要做的：

先决条件

此大小的卷必须由RAID支持。定期的磁盘错误会导致伤害。
不过，RAID是不是一个备份。您还必须将贵重物品存放在其他地方。
首先调整大小并验证所有周围的卷（分区表，加密，lvm）。
更改硬件RAID配置后，Linux可能会或可能不会立即确认新的最大大小。检查$ cat /proc/partitions并在必要时重新启动。

使用最新的稳定内核和e2fsprogs

确保（检查uname -r）您正在运行的内核可以正确处理64位ext4文件系统-您要使用4.4.x内核或更高版本（默认的Ubuntu 16及更高版本）。
获取至少版本的e2fsprogs 1.43
- Ubuntu 16.04（2016-04-21）与e2fsprogs 1.42.12（2014-08-25）一起发布
- e2fsprogs 1.43 （2016-05-17）是第一个能够升级extfs地址大小的版本。
- Ubuntu 18.04（2018-04-26）附带e2fsprogs 1.44.x（好！）

如果您正在使用16.04且无法升级到较新的Ubuntu版本，则必须启用源软件包支持并手动安装较新的版本：

$ resize2fs
# if this  prints version 1.43 or above, continue to step 1
$ sudo apt update
$ sudo apt install git
$ sudo apt build-dep e2fsprogs
$ cd $(mktemp -d)
$ git clone -b v1.44.2 https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git e2fsprogs && cd e2fsprogs
$ ./configure
$ make
$ cd resize
$ ./resize2fs
# this should print 1.43 or higher
# if this prints any lower version, panic
# use `./resize2fs` instead of `resize2fs` for the rest of the steps

调整大小

步骤1：正确卸载文件系统

$ sudo umount /dev/mapper/target-device

步骤2：检查文件系统是否有错误

$ sudo e2fsck -fn /dev/mapper/target-device

步骤3：在文件系统中启用64位支持

咨询man tune2fs和man resize2fs-你可能会改变一些文件系统的标志。

$ sudo resize2fs -b /dev/mapper/target-device

在典型的HDD RAID上，这需要4分钟的高IO和CPU负载。

步骤4：调整文件系统大小

$ sudo resize2fs -p /dev/mapper/target-device

如果未在命令行上传递大小，则resize2fs会假定“增加到所有可用空间”-通常正是您想要的。该-p标志启用了进度条-但是这些进度条仅在某些初始步骤之后显示。

在典型的HDD RAID上，这需要4分钟的高IO和CPU负载。

再次验证

再次检查文件系统

$ sudo e2fsck -fn /dev/mapper/target-device

较新版本的e2fsck可能建议修复先前版本处理不当的时间戳或扩展树。这并不表示存在任何严重问题，您可以选择现在或以后进行修复。

如果发生错误，请不要惊慌，也不要尝试写入该卷。请咨询对文件系统有广泛了解的人，因为进一步的操作可能会破坏数据！

如果没有错误，请重新安装设备：

$ sudo mount /dev/mapper/target-device

成功！

您不需要任何非Ubuntu版本的e2fsprogs即可继续运行已升级的文件系统-内核在相当长的一段时间内一直支持这些文件系统。只需要启动升级。

作为参考，如果要求创建具有不合适选项的大型设备，则会显示类似的错误消息mke2fs：

$ mke2fs -O ^64bit /dev/huge
mke2fs: Size of device (0x123456789 blocks) is too big to be expressed in 32 bits using a blocksize of 4096.

— x
source

1

这是对的。我想补充一点，在对超过16TB的文件系统进行分区时，Redhat（因此RHEL，Centos等）在安装程序中倾向于使用XFS而不是Ext4，现在只是直接选择XFS作为默认文件系统。

— 暗黑破坏神D3，

是的，在RedHat World中仍然很重要的大多数较旧的内核尚未包含对64位ext4的稳定支持。Afaik Ubuntu遵循许多Linux专家所说的话，ext4将被btrfs取代-尽管ext4现在在功能上已接近btrfs，但我相信btrfs的设计更优雅，甚至更不容易出现错误。

— 斧头2016年

2

btrfs尚未准备好生产，并且可能永远也没有准备好生产，因为Oracle已将btrfs的开发推迟了。我个人的意见是，如果您需要这种级别的文件系统复杂性，请使用8GB XFS微型根目录和ZFS结合使用以满足实际数据存储需求。

— Diablo-D3

0

最近发生在我身上，一个Ubuntu 18.04在最初安装一个16.04 Ubuntu之后进行了更新...该存储阵列（/ dev / sdb）最初已划分为两个14 TB分区，这就是想扩大发生问题的第一个分区到28 TB。

我不需要下载新版本的resize2fs，因为它是最近的。

# resize2fs 
resize2fs 1.44.1 (24-Mar-2018)

唯一的问题是要转换已格式化为32位的64位分区1 ...我不建议读者参考tune2fs的文档（正如Anx所建议的），而是提出一个真实的示例！

# tune2fs -O 64bit /dev/sdb1
tune2fs 1.44.1 (24-Mar-2018)
Please run "resize2fs -b /dev/sdb1" to enable 64-bit mode.

# resize2fs -b /dev/sdb1
resize2fs 1.44.1 (24-Mar-2018)
Convert the file system to 64 bits.
The file system on /dev/sdb1 now has a size of 3662109119 blocks (4k).

最后，我们扩大磁盘分区！

# resize2fs /dev/sdb1
resize2fs 1.44.1 (24-Mar-2018)
Resizing the file system on /dev/sdb1 to 7324303099 (4k) blocks.
The file system on / dev / sdb1 now has a size of 7324303099 blocks (4k).

— 马克西·瑞格斯
source