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

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

来自新手SysAdmin的问题(长时间* nix用户).

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

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

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

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

解决方法

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

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

在临时文件系统上执行繁重的I / O时,也可以杀死(或杀死-9)您的作业,以确保没有其他I / O排队.