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

Question

编辑:执行摘要(-详细的版本下面)：我需要一台机器，以迅速关闭电源中断，因为短的电池寿命。有什么理由我不应该使用'umount -f‘(嵌入在一个电源故障-用例脚本中)在刮擦驱动器，其IO阻碍了关闭，谁的数据，我不在乎谁的工作是否死了？

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

最近，我设置了一个CentOS计算服务器，并与我的UPS进行了对话，这样，当我们失去电源时，它就会优雅地关闭(这就是我所有的钱)。在我还没来得及拔掉插头之前，当地的电力公司就开始测试这个了(哎呀！)这给我提供了一些非常紧张的时刻，而卸载文件系统需要10分钟左右，在最后关闭之前，电池达到了12%。

这花了这么长时间，因为我在机器上塞满了大量的IO任务，准备进行一个简单的测试，即发出一个“暂停”命令，看看关闭需要多长时间。沉重的IO都会在RAID0中的专用驱动器上占用一个划痕空间。如果工作结束了，我就不在乎那些硬盘上有什么了。在这样的失败之后，我甚至可以重新构建文件系统。如果任何较轻使用的驱动器(家庭脏)被破坏，如果电池在关闭之前死亡，这将是一个痛苦。

也就是说，apcupsd有一个位置让sys插入一个bash脚本，在满足特定条件时执行该脚本。如果这种情况是电源故障，而且我真的不关心为了快速关闭而损坏划痕数据，那么'umount -f‘是我的朋友吗？

有什么我没考虑的吗？在此之后，我需要重新创建文件系统吗?还是只删除驱动器上损坏最严重的文件？

Answer 1

假设您确实找到了长期关闭的根本原因，以及您对该特定文件系统上的数据完整性缺乏关注，那么您肯定应该尝试执行一个umount -f。

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

最好也杀死(或杀死-9)执行刮擦文件系统上重I/O的作业，以确保没有额外的I/O排队。