问题resize2fs
:在大型(8-28Tb)ext4 文件系统上进行离线收缩操作“第 2 遍”期间,进度条指示什么?
细节:
我已经resize2fs
使用(“进度”)标志执行了大约 5 次收缩操作-p
,但我不知道“第 2 次”的“进度条”在告诉我什么。示例输出如下。
进度条一开始全是破折号,部分用 X 填充,但 X 的数量增加和减少在整个操作过程中,在每种情况下,操作都已完成,但进度条未完成。有时,当第 2 遍完成时,进度条已部分填满,如下面的示例输出所示,但至少有一种情况,它完成时没有 X(“空”),尽管操作期间有 X。有时,X 的数量在整个操作过程中会增加和减少多次;例如,从 0 个 X 增加到 8 个 X,然后减少回 0,然后增加到 6,然后回到 0,然后增加到 6 并完成。
# resize2fs -M -p /dev/media/media
resize2fs 1.45.4 (23-Sep-2019)
Resizing the filesystem on /dev/media/media to 820975573 (4k) blocks.
Begin pass 2 (max = 369742748)
Relocating blocks XXXXX-----------------------------------
Begin pass 3 (max = 44944)
Scanning inode table XX--------------------------------------
系统:PopOS 20.04(基本上是 Ubuntu 20.04)。1.45.4 resize2fs
。如果有其他相关版本可以包含在这里,请告诉我。
先前的研究:
手册页只是提到“完成百分比”:
在离线调整大小期间打印出每个 resize2fs 操作的完成百分比条,以便用户可以跟踪程序正在执行的操作。
...但第二阶段的行为不符合该描述,但增加和减少似乎表明它正在尝试沟通某物。
我已经在 Google、ServerFault 和 SuperUser 上搜索了“resize2fs 收缩进度条”、“resize2fs 进度”和类似的查询。
我发现了另外 2 个关于此行为的引用,但没有解释进度条指示的内容:
- Resize2fs 进度条不可靠在 Ubuntu 论坛上发帖,没有回复。
- 在估计 resize2fs 收缩所需的时间,提问者在问题末尾的“编辑”中以及对 John Mahowald 的最佳答案的评论中提到了这种行为。
答案1
我认为用于显示进度条的代码中存在整数溢出错误: https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/tree/resize/sim_progress.c?h=v1.47.0#n55
条宽设置为 40,
max = 369742748(来自您的示例)乘以 40 大于有符号整数的最大值(取决于平台?)
计算要移动的块数时也存在整数溢出错误 https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/tree/resize/resize2fs.c?h=v1.47.0#n1763
然后将此有符号整数转换为无符号长整型,这会导致输出中出现巨大的数字,如我的情况所示:
Resizing the filesystem on /dev/mapper/vg_vg-lv_lv to 20401094656 (4k) blocks.
Begin pass 2 (max = 18446744071821778183)
我认为,在缩小大型文件系统时,进度条目前毫无用处。