估计 resize2fs 收缩所需的时间

Question

我有一个很大的 ext4 文件系统，我目前正在缩小它（在我的情况下为 109Tb -> 83Tb），并且需要很长时间（询问时的第 5 天）。目前我可以通过iotop. 然而，从互联网上粗略一瞥，似乎 resize2fs 并没有像增加卷（大约 2011 年）那样针对收缩进行优化。

就此而言，如果我能帮上忙，我不想打断它，但我觉得这么长时间运行文件系统更改有点赤裸裸。考虑到我们知道前后的空间需求（以及块数/块大小），ext4 收缩的正确/及时估计是什么？

涉及软件：

• e2fs...：1.43.1
• 操作系统： debian 4.19.16-1-bpo9+1

我的特定文件系统：

• 类型：ext4
• 大小：~109Tb（29297465344 个块）
• 缩小到：83Tb（22280142848 块）
• 块大小：4Kb（4096 字节）
• 每个 inode 的字节数：2^15（32786 字节）

当前输出：

resize2fs -p ...：

[root@devlynx]## ~:: resize2fs -p /dev/storage/storage 83T
resize2fs 1.43.4 (31-Jan-2017)
Resizing the filesystem on /dev/storage/storage to 22280142848 (4k) blocks.
Begin pass 2 (max = 802451420)
Relocating blocks             XX--------------------------------------

iotop：

   TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
  7282 be/4 root       39.21 M/s   39.21 M/s  0.00 % 94.07 % resize2fs -p /dev/storage/storage 83T

cat /proc/7282/io：

rchar: 12992021859371
wchar: 12988874121611
syscr: 13244258
syscw: 12482026
read_bytes: 13003899662336
write_bytes: 12988874125312
cancelled_write_bytes: 0

我仍在查找有关resize2fs需要执行的不同传递的信息，以及根据我获得的有关文件系统的信息（如果需要，我还有更多），我如何计算这些传递所需的时间。简而言之，我如何才能对这需要多长时间做出最终估计？

编辑：这实际上是完成的Pass 2吗？

[root@devlynx]## ~:: resize2fs -p /dev/storage/storage 83T
resize2fs 1.43.4 (31-Jan-2017)
Resizing the filesystem on /dev/storage/storage to 22280142848 (4k) blocks.
Begin pass 2 (max = 802451420)
Relocating blocks             XX--------------------------------------
Begin pass 3 (max = 894088)
Scanning inode table          XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 4 (max = 92164)
Updating inode references     XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/storage/storage is now 22280142848 (4k) blocks long.

Answer 1

粗略的估计可以帮助说明事物的规模，即使是简单化的并且一点也不准确或精确。假设需要读取全部1.2E+14字节，每秒可以维持4E+7字节。即3E+6秒，即34天。resize2fs大约 5 天时 5% 的进度条似乎是 10 的正确幂。

至少还有几周时间。

该卷何时需要恢复使用？对于现在需要升级的内容，与您可以花一个月时间保存但不能立即使用的存档相比，紧迫性不同。

如果中断，您是否准备好丢失数据？没有一种优雅的方法来阻止它，因此有可能发生腐败。成功的归约已经发生，但并不常见，并且在块周围重新洗牌的过程中停止归约更不常见。无论此文件系统发生什么情况，请检查与fsck. 准备好恢复计划并备份重要数据。

即使这次尝试最终失败，这个数量还必须减少吗？安全的方法是创建一个新的、更小的文件系统并复制数据。明显的缺点，这需要新的存储。也许借此机会进行存储迁移或其他需要阵列重建或类似的事情。