我们的任务是将 LVM 中的文件系统大小从 8T 调整为 7T。我们已经给出了 resize2fs 命令，当该命令仍在运行时，我们收到错误“写入失败：连接被对等方重置”，但是当我们再次登录时，resize2fs 命令仍在运行进程列表。该过程完成后，我们使用“lvreduce”减少了 LVM 并将其安装回来。
现在，在 df -h 中，它仍然显示 8TB，但在 LVM 中，它显示 7TB。如何纠正这个问题？
答案1
resize2fs可能没有完成工作，但你无法判断，因为你错过了其输出的结尾。
你应该不是lvreduce那时已经继续并执行了。这很有可能损坏了您的文件系统的一部分。请注意，您无法通过运行lvextend并希望丢失的字节返回并且文件系统可以恢复来撤消此操作，因为lvextend可能会返回不同的字节。
如果我不得不猜测，可能发生的情况是您的连接在resize2fs工作一段时间而没有发出任何输出的情况下被重置。连接重置后，它继续运行一段时间（它忽略SIGHUP或从未收到它？）。但后来，可能当它几乎完成时，它发出了一些状态输出并立即被终止，因为它收到错误或信号试图写入不存在的终端。但它从未完成。
resize2fs文件系统处于什么状态是一个悬而未决的问题，但人们可以希望它使其处于相当可用的状态，而文件系统大小的减小并未得到落实。
这部分故事的寓意是：如果您的连接有可能被中断，请执行关键操作，例如resize2fsunder screen（或作为jobs，或其他）。at
无论您做什么，请确保您有良好的备份，因为此时您可能尝试的任何操作都是危险的。如果您没有良好的备份，您可以将文件系统挂载为只读（不要将其挂载为读+写，因为这可能会加剧损坏）并立即获取一个。
最安全的方法是删除文件系统并从备份中恢复。但是，如果您想尝试将文件系统恢复到位，您可能需要执行这两个任务的某种组合：
fsck文件系统按原样。这将通知您任何超出文件系统末尾的读取尝试，并可能让您了解有多少数据超出了这些范围。希望不会太多，因为resize2fs可能在崩溃之前成功移动了这些数据。- 将块设备使用重新扩展
lvextend为以前的大小，只是为了使文件系统满意，然后fsck从第一个方向再次尝试整个操作。当文件系统访问超出有效数据所在范围的字节范围时，这可能会导致一些静默损坏。
我不确定什么最适合您。这取决于文件系统上发生的事情的布局以及自事件发生以来它被触及的程度（您提到您已经安装了它，可能是读+写，至少一次......）