filesystems - 刚刚开始进行大规模删除的完整 UFS 上的 open() 非常慢（超过 6 秒）？

Question

我们在 solaris 上有一个 UFS 分区。

音量已满。我们仍在尝试写入它 - 自然 open() 立即返回 -1。

当启动执行大规模删除的 cronjob 时，看起来 open() 没有及时返回 - 它至少需要六秒钟，因为这是看门狗杀死进程之前的时间。

现在，显而易见的想法是删除使文件系统保持忙碌，而 open() 只需要永远......但是有关于这种行为的具体知识吗？

Answer 1

批量删除会导致随机 IO 风暴，这确实会损害性能。它使尽可能多的日志/日志事务提交（尝试使用nologging选项？）。此外，如果您的 fs 快满了，那么 open 无论如何都需要一些时间来为新的 inode 寻找空间。

更频繁地删除文件，一次更少，可以帮助您缩短响应时间。或者干脆更慢地删除它们，在 rm 之间休眠。

Answer 2

也许可以更改执行“批量删除”的程序以在有问题的文件系统上更顺畅地运行。如果它确实查询以查找要删除的文件，则可能不是打开调用超时。为了测试这个理论，有没有办法设置一个 cron 作业，在磁盘满状态下简单地删除一个具有已知名称的文件？“批量删除”程序如何决定要进行什么“打开”调用？

还可以在写入停止工作之前控制磁盘利用率的百分比。您也可以尝试将其设置为较低的百分比。如果您通过等待文件创建步骤返回 -1 来检测“磁盘已满”状态，那么您应该考虑向您的代码添加显式检查，以便如果文件系统已满某个百分比以上，请采取纠正措施。