☰

估计 resize2fs 收缩所需的时间

tag-icon • tag-icon linux debian filesystems lvm ext4
估计 resize2fs 收缩所需的时间

我有一个大型 ext4 文件系统，目前正在缩小它（我的情况是 109Tb -> 83Tb），这花费了极长的时间（询问时是第 5 天）。目前我可以看到该过程仍在通过 进行 I/O（因此似乎没有出错和停滞，即 100% CPU 使用率）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需要执行的不同过程的信息，以及如何根据我获得的有关文件系统的信息（如果需要，我还有更多信息）计算这些过程需要多长时间。简而言之，我如何才能最终估计这将需要多长时间？

编辑：这实际上是完成的第 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.

答案1

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

至少还要几周的时间。

这个卷什么时候需要重新投入使用？对于需要立即上传的内容，与不立即使用、可以花一个月时间上传的档案，紧急程度有所不同。

如果中断，您是否做好了数据丢失的准备？没有一种优雅的方式来阻止它，因此可能会损坏数据。成功的 Reduce 曾经发生过，但这种情况并不常见，在重新排列块的过程中停止 Reduce 就更少见了。无论这个文件系统发生什么，都要检查一致性fsck。准备好恢复计划，并备份重要数据。

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

答案2

由于只有另一个答案，我想我将提供我有限的经验。

我运行约 5 次resize2fs缩减的经验是，将要缩减的数量（在 OP 的情况下为 109Tb - 83Tb = 26Tb）除以工具报告的写入速度，iotop得到的估计时间略大于该过程实际花费的时间；我的调整大小花费了该时间的 70-90％。

OP 在对 John Mahowald 的回答的评论中报告说，最终过程耗时“大约一周”。这与我的经验相符，因为 OP 报告的速度为 40 meg/sec。40 iotop* 60 * 60 * 24 * 7 = 24,192,000 meg，或约 23Tb，约为 26Tb 缩减大小的 88.7%。

我总是将其调整到包含存储数据的最小尺寸（-M），并且我推测这种调整大小所需的时间比缩小大部分为空的卷的时间更长，因为我们可以想象需要重新定位更少的分配块。

OP 对第二阶段“进度条”的体验与我的一样：我无法收集到任何有意义的进度指示，第二阶段结束时进度条几乎是空的。此外，“进度条”上的 X 数量会增加并减少根据我的经验，有时会多次上升和下降。我曾看到它增加到 8 个 X，然后减少到 0，最后以 0 结束。我还看到它以其他数量的 X 结束，比如 2 个或 6 个。我不知道如何解释这个“进度条”告诉我的内容，并打算就此发布我自己的问题。

OP 的缓慢数据速率也符合我的经验。尽管相关磁盘能够实现 80-120meg/sec 的连续写入速度，但我的调整大小速度约为 40meg/sec。我的块大小为 4k。如果驱动器一次重新定位一个块，这可能就像随机 4k 读写一样——一个非常繁重的寻道操作。我的resize2fs进程似乎也消耗了整个 CPU 核心（100% 的 CPU 使用率）。

相关内容