私たちはsolaris上にUFSパーティションを持っています。一括削除を開始したフルUFS上でopen（）（6秒プラス）が非常に遅いですか？
ボリュームがいっぱいになります。私たちはまだそれに書き込もうとしています。自然にopen（）が直ちに-1を返します。
大量消去を実行するクロノスが起動すると、open（）がタイムリーに返されないように見えます。ウォッチドッグがプロセスを殺すまでの時間は少なくとも6秒です。
削除がファイルシステムをビジー状態に保ち、open（）が永久にかかることは明らかですが、そこには何らかの具体的な知識がありますか？
恐らく、「大量削除」を行っているプログラムは、問題のあるファイルシステムでよりスムーズに動作するように変更することができます。削除するファイルを見つけるためにクエリを実行すると、タイムアウトしたオープンコールではない可能性があります。理論をテストするために、ディスクフル状態の間に既知の名前を持つ単一のファイルを単純に削除するcronジョブを設定する方法はありますか？ 「大量削除」プログラムは、どのような「開かれた」呼び出しを決定するのですか？
書き込みが動作を停止する前にディスク使用率を制御することもできます。これを低いパーセンテージに設定することもできます。ファイル作成ステップが-1を返すまで待って「ディスクがいっぱい」の状態を検出している場合は、コードに明示的なチェックを追加して、ファイルシステムが一定の割合を超えた場合に修正処置をとることを検討する必要があります。
一括削除はランダムIOの嵐を引き起こし、実際にはパフォーマンスを傷つけます。コミットするジャーナル/ログトランザクションを多くします（nologgingオプションを試してみてください）。さらに、あなたのファイルがほぼいっぱいになると、新しいinodeのためのスペースを見つけるのに時間がかかるでしょう。
ファイルを頻繁に削除すると、一度に削除する回数が減り、応答時間が短縮される場合があります。または単にそれらを遅く削除し、rmの間で寝ます。