![resize2fs 似乎卡在第 3 步(扫描 inode 表)——该怎么办?](https://linux22.com/image/1279784/resize2fs%20%E4%BC%BC%E4%B9%8E%E5%8D%A1%E5%9C%A8%E7%AC%AC%203%20%E6%AD%A5%EF%BC%88%E6%89%AB%E6%8F%8F%20inode%20%E8%A1%A8%EF%BC%89%E2%80%94%E2%80%94%E8%AF%A5%E6%80%8E%E4%B9%88%E5%8A%9E%EF%BC%9F.png)
我有一台运行 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)。