4000以上のディレクトリに600万以上のファイルがあり、合計で約26GBのデータがある巨大なディレクトリを削除したいと思います。しばらく時間がかかることがわかっていたので、ionice
を使用してI/O優先度をアイドルに設定したので、ファイルが削除されている間も他のタスクを続行できます。
time ionice -c3 rm -vrf /tmp/huge-folder
しかし、私のデスクトップ環境全体は今では非常に遅くなっていますが、Google chromeは、新しいタブを開いてページを読み込むのに時間がかかり、新しいxtermウィンドウを開くのに時間がかかることもあります。要約すると:私は表示されますrm
プロセスでのI/O優先度の低下によるメリットをまったく享受できません。
iotop
で状況を調べると、I/O時間の一部がrm
プロセスで必要なidle
I/O優先度で費やされていることがわかります。
しかし、その後、I/O時間がext4のジャーナリングプロセスとソフトウェアレイドプロセスに費やされることもあります。
彼らがどのように独自のデフォルトI/O優先度を使用しているかに注意してください。これがおそらく問題の原因です。 jbd2
は優先度be/3
で実行されますが、これは実際、他のすべてのデスクトッププロセスのデフォルトのbe/4
よりも高い優先度です。
他の多くの質問jbd2
とは何か、なぜI/O時間がかかるのかを尋ねて答えてください。それは、私が疑問に思っていることではありません。私の質問は、この特定のシナリオでアイドルI/Oスケジューリングの優先順位を本当に取得する方法はありますか?明らかに、ionice
をjbd2
に適用するのはおかしなアイデアです。
詳細なセットアップ情報:これは、3つの回転ディスクを備えたソフトウェアraid10上のext4ファイルシステムにあります。 ext4は、デフォルトのオプションを使用してフォーマットおよびマウントされます(Debianのデフォルト、それらが異なる場合)。
私はこれを尋ねたので、LinuxカーネルでのI/Oの仕組みについて多くのことを学び、ionice
はほとんどの書き込み操作では機能しないという結論に達しました。
読み取り操作はほとんど同期しており、非常に簡単に優先順位を付けることができます。おそらく、最適化、集約などのために、後で(したがって非同期で)遅延されることが多い書き込み操作では、これはかなり困難になります。その方法で優しさの情報を転送して正しく集約することは容易ではないと想像できます。
出典: Linuxのioniceに関するいくつかのメモ 。このソースでは、ionice
がLVMまたはソフトウェアRAIDで機能しないことにも言及していますが、それがまだ正しいかどうかについては疑問があります(ブログ投稿は少し古いです)。
以下も参照してください: ioniceは同期されていない書き込み(つまり通常の書き込み)には影響しませんか?