btrfsにおける頻繁なduの性能と影響

私が理解したところ、duはstatsを使用してRAMにキャッシュされたinode情報を読み取ります。そうですか？それともディスクキャッシュですか？それとも両方？

「RAMにキャッシュされる」：ある程度はそうです。正確ではありませんが、ファイルシステムバッファもRAMを消費し、100000個のinode/範囲リストにもRAMが必要なので「両方」です。 （「ディスクキャッシュ」は意味がありません。データ構造はディスク上にあるため、これはキャッシュではなく基本データです。）

上記が正しい場合、duを頻繁に実行すると、次のような結果が出ると想定できます。

• システムのパフォーマンスに悪影響を与えません。

あなたはそれを仮定することはできません。ファイルシステム全体がRAMに常駐していても、これは依然としてデータ集約的な作業であるため、CPU、RAM、およびドライブインターフェイスの帯域幅を使用します。

スピンドルに不要な摩耗が発生しませんか？議論の余地がある問題かもしれませんが、ユーモラスに考えてみてください。

スピンドル摩耗を見たことがないので、うん、いや？また、ハードドライブを使用すると回転速度が速くなるため、この質問がよく考慮されているかどうかはわかりません！

私はdu出力のための一種のキャッシュを提供するいくつかのツールについて読んだが、私の目標は違いを捉えることであり、議論に関連しているかどうかはわかりません。

変化を追求してみると後退することもあります。duおそらくいいえその後、ツールを選択してください！

1. 実際には、inotifyを使用してファイルのプロパティの変更に関する通知を受け取ることができます。これは、いくつかの変更を適用するためにファイルシステム全体をナビゲートするよりも負荷がかかりません！
2. duBTRFSへ使用されているストレージスペースについてだます。。 Btrfsはスマートです。コピーされたファイルは作成する前に追加のリポジトリを必要とせず、スパースファイル領域も必要ありません。スナップショットとサブボリュームの概念により、これらすべてが概念的に多少難しくなります。duすべてのファイルサイズを合計するだけです。いいえ、同じです。ディスク使用量！

du解決したい問題を詳しく説明し、現在のアプローチを説明する新しい質問（コメントではなく新しい投稿）を尋ねることをお勧めします。ここであなたの質問は非常に具体的なアプローチの小さな側面の1つについて尋ねるようです。これが実際の問題を解決できるかどうかはわかりません！