编辑：执行摘要（--下面是详细版本）：我需要一台机器，由于电池寿命短，在断电时能快速关闭。有什么理由我不该对暂存驱动器使用“umount -f”（嵌入在电源故障情况脚本中）吗？该暂存驱动器的 IO 正在阻止关机，而且如果作业已经终止，我也不关心其数据。
来自新手系统管理员（长期 *nix 用户）的问题。
我最近设置了一个 CentOS 计算服务器，并让 apcupsd 与我的 UPS 通信，这样一旦断电（我只有钱买这个），它就会正常关机。在我忍不住拔掉电源插头之前，当地电力公司就开始测试这个了（天哪！）。这让我非常紧张，因为卸载文件系统花了 10 分钟左右，电池电量降至 12%，最后才关机。
之所以花了这么长时间，是因为我在机器上塞满了繁重的 IO 作业，为发出“halt”命令的简单测试做准备，看看关机需要多长时间。繁重的 IO 全部进入 RAID0 中专用驱动器上的暂存空间。如果作业失败，我根本不在乎这些驱动器上有什么。我甚至可以在发生此类故障后重建文件系统。如果电池在关机完成之前耗尽，任何使用较少的驱动器（主目录）损坏，那将是一件痛苦的事情。
话虽如此，apcupsd 为系统管理员提供了一个插入 bash 脚本的地方，该脚本在满足某些条件时执行。如果该条件是电源故障，而我真的不介意为了快速关机而破坏临时数据，那么“umount -f”是我的好朋友吗？
有什么我没有考虑到的吗？在此之后我是否一定需要重建文件系统，或者只是删除驱动器上最有可能损坏的文件？
答案1
假设您确实找到了长时间关机的根本原因，并且找到了您对特定文件系统上的数据完整性缺乏关心的原因，那么您绝对应该尝试执行umount -f。
但是，我认为这不太可能解决您的问题：umount -f 可以解决无响应的 NFS 服务器和打开的文件句柄问题，但它仍会将缓冲数据写入文件系统。如果您已经有如此多的数据在传输中，您的 umount 脚本仍将需要很长时间。
终止（或 kill -9）在暂存文件系统上执行繁重 I/O 的作业可能是一个好主意，以确保没有额外的 I/O 排队。