我们有一项任务是将文件系统从8T调整到7T,这是在LVM中.我们已经给出了resize2fs命令,当命令仍在运行时,我们收到错误“写入失败：连接由对等方重置”,但是当我们再次登录时,resize2fs命令仍在运行进程列表.在完成该过程后,我们使用“lvreduce”减少了LVM并将其重新安装.

现在在df -h它仍然显示8TB,但是在LVM中它显示7TB.如何纠正这个问题？

解决方法:

resize2fs可能没有完成这项工作,但你无法分辨,因为你错过了它的输出结束.

你不应该在那时继续执行lvreduce.这个文件系统损坏的部分很有可能.请注意,您无法通过运行lvextend并希望丢失的字节返回以及文件系统可以恢复来撤消此操作,因为lvextend可能会返回不同的字节.

如果我不得不猜测,可能发生的事情是你的连接在resize2fs工作一段时间而没有发出任何输出的时候重置了.重置连接后,它会继续运行一段时间(它忽略了SIGHUP或从未收到它？).但是稍后,可能在它几乎完成时,它会发出一些状态输出并被迅速杀死,因为它有错误或信号试图写入不存在的终端.它从未完成.

什么状态resize2fs离开文件系统是一个悬而未决的问题,但人们可以希望它使它处于一个相当可用的状态,文件系统大小减少未提交.

故事的这一部分的道德：如果您的连接可能被中断,则在屏幕下(或在作业或其他任何情况下)执行resize2fs等关键操作.

无论你做什么,请确保你有一个很好的备份,因为你在这一点上可能尝试的任何事情都是危险的.如果你没有一个好的备份,你可以将文件系统挂载为只读(不要挂载读写,因为这会加剧损坏)并立即取一个.

最安全的是删除文件系统并从备份中恢复.但是,如果您想尝试恢复文件系统,您可能希望执行这两个任务的某些组合：

>按原样fsck文件系统.这将通知您任何超出文件系统末尾的读取操作,并且可能会让您了解有多少数据超出了这些范围.希望不多,因为resize2fs可能在崩溃之前成功移动了数据.
>使用lvextend将块设备重新扩展到以前的大小,只是为了使文件系统满意,然后fsck,然后从方块1再次尝试整个操作.当文件系统访问超出有效数据所在范围的字节范围时,这可能会引入一些静默损坏.

我不确定哪种方法最适合你.这取决于事件碰巧在文件系统上的布局以及自事件发生以来它被触摸的程度(你提到它已经安装了它,可能是读写,至少一次……)