估计resize2fs收缩所需的时间

Question

我有一个大型的ext4文件系统，我目前正在缩小它(在我的例子中是109 of -> 83Tb )，它花费了非常长的时间(第5天开始询问)。目前，我可以看到，进程仍然在做I/O (因此，它似乎还没有错误和停止，即100%的cpu使用率)通过iotop。然而，粗略地浏览一下互联网，resize2fs似乎并没有像规模的增长那样优化收缩(大约在2011年左右)。

对于这个问题，如果我能帮上忙的话，我不想打断它，但是我觉得在这么长时间内运行一个文件系统更改时，我感觉有点赤裸裸。如果我们知道ext4收缩前后的空间需求(以及块/块的大小)，那么正确/及时的估计会是什么？

Software涉及：

• e2fs.：1.43.1
• OS：debian 4.19.16-1-bpo9+1

My特定的文件系统：

• 类型: ext4
• 尺寸：~109 (29297465344块)
• 收缩至: 83Tb (22280142848块)
• 块大小: 4Kb (4096字节)
• 字节-每个inode: 2^15 (32786字节)

Current输出：

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.

Answer 1

粗略的估计可以帮助说明一件事情的规模，即使过于简单，而且一点也不准确或精确。假设需要读取所有1.2E+14字节，并且可以维持每秒4E+7字节。这是3E+6秒，也就是34天。resize2fs 5%进度栏在大约5天似乎是正确的力量10。

至少还有几个星期。

此卷何时需要恢复服务？对于现在需要提升的东西的不同的紧迫感，与无法立即使用的存档相比，您可以花一个月的时间。

如果数据丢失被中断，您准备好了吗？没有一个优雅的方法来阻止它，所以有腐败的机会。成功的减少已经发生，但它们并不常见，而且在街区周围的重组中停止减少的情况就更少了。无论这个文件系统发生了什么，都要检查与fsck的一致性。准备好恢复计划，备份重要数据。

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

Answer 2

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

我运行~5 resize2fs收缩的经验是，将要收缩的数量(在OP的情况下为109 Tb-83Tb=26 to )除以iotop之类的工具所报告的写入速度后，估计的时间比实际花费的时间稍大一些；我的大小花费了70%-90%的时间。

OP在对的回答的评论中说，最终的过程“大约需要一个星期”。这与我的经验相吻合，据iotop的OP报告，每秒钟40 meg。40 * 60 * 60 * 24 *7= 24,192,000 meg，约23 of，约为26 of减少尺寸的88.7%。

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

OP使用pass 2“进度条”的经验与我的相匹配:我无法收集到任何有意义的进度指示，而pass 2总是以一个大部分为空的进度条结束。此外，在我的经验中，“无进度条”上的Xs数量增加或减少，有时上升或下降多次。我看到它上升到8倍，然后下降到0，以0结束。我也看到它和其他X的数一起完成，比如2或6。我不知道如何解释这个“进度条”在告诉我什么，并打算就此发表我自己的问题。

OP的缓慢数据速率也符合我的经验。我的大小发生在40 My /秒左右，尽管所讨论的磁盘能够连续写入80-120 My/秒的速度。我的积木是4k大小的。如果驱动器一次重新定位一个块，这可能就像随机的4k读/写操作--这是一个非常需要查找的操作。我的resize2fs进程似乎也消耗了整个CPU核心(100%的cpu使用率)。