将 SIGINT 发送到负责缩小的 resize2fs 有多危险？

Question

我继承了旧电脑，服务器（四奔腾4）只有分区的/，/boot和swap（RAID1 2个1T SATA磁盘），但更新（从CentOS的6.9）的发行需要。我决定创建一个新分区，以便/可以格式化包含的分区。

但是我忘记添加-p标志resize2fs，现在它默默地盯着我看，我不知道它需要多长时间（它已经持续了 50 多个小时）。现在，我知道缩小文件系统可能需要很长时间，但是虽然我可以等待100 小时，但800 小时之类的时间是不可能的。

这是我目前的想法：

• 继续使用Ctrl+ C&& e2fsck。
• 挂载分区并手动删除价值 100G+ 的无用数据。
• 从顶部开始 resize2fs -p ...

但我一直没能找到共识上是多么危险的是送SIGINT到resize2fs。

我确实有重要信息的额外备份，但仍然希望在不损坏文件系统的情况下执行此操作。是的，我知道从头开始安装发行版并恢复备份可能会更快。

更新：我决定打断它。一切似乎都很好，但问题仍然存在。我还是很好奇。

Answer 1

绝对是一个有趣的问题，虽然你的结果相当不错（正如我所希望的，因为捕捉SIGINT并不是完全火箭科学，中途暂停只是重新定位一些数据块似乎也不难），但也有足够多的非成功案例，例如 10yo Debian bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574292

但是，即使这个bug是10Y的时候，我刚刚跑了模拟e2fsck，并resize2fs通过strace和，而前者安装一大堆信号处理程序，包括SIGINT和SIGTERM，resize2fs仍然没有。

所以如果有人发现这个问题：把以上作为轶事证据，继续提防。:-) 请注意，手册页确实提到了用于在出错时创建撤消文件的标志。

（而我，我只是希望我在屏幕会话中运行此调整大小操作......但至少我确实有-p）

编辑

等等，我刚刚意识到，为什么不通过 SSH 进入，制作 LVM 快照e2fsck，而调整大小仍在运行？我在“重定位块”阶段连续做了 5 次，尽管每次检查我都得到“包含一个有错误的文件系统，强制检查”，但它从未发现任何错误。现在当然不要问我关于数据完整性的问题。

编辑

来自 tytso@ 本人 BTW 在https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574292#30 的非常有趣的回复