在非nfs卷上的umount -f总是邪恶的吗?

Modified on: Mon, 08 Jul 2019 15:00:02 +0800

编辑:执行摘要( - 下面的版本):由于电池寿命短,我需要一台机器在停电时快速关闭。有没有理由我不应该在暂停关机的暂存驱动器上使用'umount -f'(嵌入电源故障案例脚本),如果工作已经死了我的数据我不在乎呢?


来自新手SysAdmin(长期* nix用户)的问题。

我最近建立了一个CentOS计算服务器,并且开始与我的UPS通话,以便在我们失去电源后立即关闭(这就是我所有的钱)。当我有胃拔插头之前,当地电力公司开始测试这个(geesh!)。这为我提供了一些非常紧张的时刻,同时卸载文件系统大约需要10分钟,在最终关闭之前将电池电量降至12%。

花了这么长时间,因为我把机器装满了大量的IO作业,为更简单的测试发出'停止'命令以查看关机需要多长时间做准备。重IO都会进入RAID0中专用驱动器的临时空间。如果工作死了,我不在乎这些驱动器上的内容。在失败之后我甚至可以重新制作文件系统。如果电池在关机完成之前死亡,任何较轻的驱动器(家用电池)都会损坏,那将是一种痛苦。

也就是说,apcupsd有一个地方让sys-admin插入一个bash脚本,当满足某些条件时会执行该脚本。如果那个条件是电源故障,我真的不在乎破坏临时数据以便快速关机,那么'umount -f'是我的朋友吗?

有什么我不考虑的吗?我是否需要在此之后重新制作文件系统,或者只是删除驱动器上最肯定损坏的文件?

最佳答案

假设您确实找到了长时间关闭的根本原因,并且您对该特定文件系统上的数据完整性缺乏关注,那么您一定要尝试执行umount -f

但是,我认为不太可能解决您的问题:umount -f将解决无响应的NFS服务器和打开文件句柄,但它仍然会将缓冲数据写入文件系统。如果你有这么多数据在飞行中,你的umount脚本仍然需要很长时间。

最好还是在暂存文件系统上执行繁重的I / O时杀死(或杀死-9)你的作业,以确保没有其他I / O排队。

作者:Urgoll

相关问答

添加新评论