☰

resize2fs 似乎卡在第 3 步（扫描 inode 表）——该怎么办？

tag-icon • tag-icon linux partitioning filesystems ext4
resize2fs 似乎卡在第 3 步（扫描 inode 表）——该怎么办？

我有一台运行 Arch Linux（我相信是 2010）的机器，其中有一个 6TB RAID-5 阵列，连接到 Highpoint RocketRaid 2320。由于驱动程序不是开源的，所以我遇到了 RAID 控制器的驱动程序和最新的 Linux 内核的问题，因此我正在将系统迁移到 Windows Server。

问题是 6TB 磁盘最初仅包含一个 ext4 分区。我尽可能缩小了分区，并在空白处添加了一个 NTFS 分区，这样我就可以开始移动文件了。一切顺利。问题是现在我需要缩小 ext4 分区再次、移动文件、再次缩小等等。第二次运行 resize2fs 所花的时间比第一次运行要长得多。它似乎在第 3 遍就卡住了：

[root@nar-shaddaa rc.d]# resize2fs -p /dev/sdb3 863000000
resize2fs 1.41.14 (22-Dec-2010)
Resizing the filesystem on /dev/sdb3 to 863000000 (4k) blocks.
Begin pass 2 (max = 29815167)
Relocating blocks             XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 3 (max = 36670)
Scanning inode table          XXXXXXXXXXX-----------------------------

它一直处于这种状态，已经占用了一个核心 100% 的能量超过 19 个小时了：

[root@nar-shaddaa rc.d]# ps aux | grep resize2fs
root     16277 94.1 19.8 627096 613940 pts/1   R+   Jun15 1184:37 resize2fs -p /dev/sdb3 863000000

我最初运行该命令是resize2fs -P /dev/sdb3为了获取最小分区大小，但为了安全起见，我将其四舍五入到最接近的百万分之一块（因此是 8.63 亿）。在启动 resize2fs 之前，e2fsck 报告文件系统为干净的：

[root@nar-shaddaa rc.d]# e2fsck -yv /dev/sdb3
e2fsck 1.41.14 (22-Dec-2010)
x-files: clean, 286672/300400640 files, 867525660/1201576187 blocks

我很担心，因为这种情况已经持续了远的比第一次调整大小所花的时间更长（不到一个小时），而且我似乎根本没有从 resize2fs 获得任何更新，但它显然在消耗 CPU 周期。我是否要等待更长时间（如果是，要等多久）？或者我是否要取消它并使用其他工具来调整分区大小？

答案1

我终于搞清楚了是怎么回事。取消原始调整大小操作（只需按 ctrl+C 键）后，我运行程序e2fsck -f -y /dev/sdb3来纠正我遇到的任何问题。我能够以原始大小安装分区，因此没有丢失任何数据。然后，我使用调试标志 ( resize2fs -d 14 <xxx>) 运行 resize2fs，并注意到它陷入了一个不断循环的状态，试图重新定位一大块 inode。

我终于通过使用较旧版本的 e2fsprogs。我将 Ubuntu 9.10 (Karmic Koala) 放在 USB 上，启动它，安装开源 rr232x 驱动程序以便我可以操作阵列，然后运行旧版本的 e2fsprogs（准确地说是 resize2fs 1.41.9（2009 年 8 月 22 日）。

我最初尝试过resize2fs -p /dev/sdb3 863000000，它告诉我需要大约 2600 万个块。所以我取了目标大小，将其添加到其中并执行了resize2fs -p /dev/sdb3 1000000000。10 分钟后，我收到了以下消息：

/dev/sdb3 现在有 1000000000 个块

现在我想最终的问题是为什么新版本的 e2fsprogs 不能/不会告诉我我要求的尺寸太小（以及为什么它一开始就提供那么小的尺寸）？

答案2

这并不能给出很好的答案，但就我的情况而言，调整大小的磁盘是错误的。我原本预计sda是 120GB，但我的 25T 存储架却在调整大小。

Anaconda 的设备清单与 CentOS 的不匹配，后者将其视为sde。因此，当我的 Clonezilla 尝试在 25T 上进行恢复时，它“卡住了” sda。如果我等了好几天，它可能会在某个时候完成。

答案3

1：有些人提到，在线调整大小期间，df -h 可能会显示变化的值。

2：离线从 7.8T 减少到 6.8T 对我来说大约需要 10-20 分钟（使用 6.6T - 可用/已用空间比率在此事中很重要）。

3：在同一台机器上，在线从 6.8T 增长到 7.6T 正好用了 2 小时（1h50'31"）。所以这对我来说是违反直觉的，但在线增长所花的时间大约是离线缩减的 8 倍。

我本来不打算执行在线增长，但在 umount 之后，我有一个 df -h 未显示的隐藏挂载点（我没有检查 mount ；只有 df）。

相关内容