btrfs での頻繁な du のパフォーマンスと影響

Question

私の理解では、du は RAM にキャッシュされる inode 情報を読み取る stats を使用します。これは正しいですか? それともディスクキャッシュですか? あるいは両方ですか?

「RAM にキャッシュ」: ある程度はそうです。完全にではありません。ファイルシステムバッファも RAM を消費し、100000 個の inode/extent リストも RAM を必要とするため、「両方」です。(「ディスクキャッシュ」はあまり意味がありません。データ構造はディスク上にあるため、それはキャッシュではなく、基礎となるデータです)。

上記が正しければ、du を頻繁に実行すると次のようになると考えられます。

システムのパフォーマンスに悪影響を与えず、

そう仮定することはできません。ファイルシステム全体が RAM 内にある場合でも、これは依然として大量のデータを使用する操作であり、CPU だけでなく RAM とドライブインターフェイスビット幅も使用します。

スピンドルに不要な摩耗を与えない？これは議論の余地があるかもしれないが、聞いてくれ

スピンドルの摩耗は見たことがないので、うーん、ないのでしょうか? また、ハードドライブは使用中に回転します。そのため、この質問が十分に検討されているかどうかはわかりません。

du 出力に何らかのキャッシュ機能を提供するツールをいくつか読みましたが、私の目的は違いを捉えることなので、それが議論に関連しているかどうかはわかりません。

変化を求めているなら、おそらく逆のアプローチをしているでしょうdu。ないでは、最適なツールです!

実際に、inotify を使用してファイルプロパティの変更について通知を受けることができます。これは、いくつかの変更を取得するためにファイルシステム全体を走査するよりも負荷が小さくなります。
dubtrfs 上使用されているストレージについてあなたを欺くでしょうBtrfsは賢いです。コピーされたファイルは、書き込むまで追加のストレージを必要としません。スパースファイル領域も同様です。スナップショットとサブボリュームの概念により、これはすべて概念的に少し難しくなります。duすべてのファイルサイズを合計するだけです。ディスクの使用状況！

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

Answer 1