これはちょうど私のコメントです「du」ダイジェストをどのようにキャッシュしたり、スピードアップしたりできますか？独自の質問で定式化されました：
du各ディレクトリの合計サイズが格納され、「バブリング」される（つまり、すべての親ディレクトリのサイズが正しく調整されるようにツリーに伝播される）、ファイルシステムを作成することについての拡張的な議論はありますか？など、それではduすぐになるのでしょうか？
上記の回答を見ると、これはI / Oパフォーマンスが低下することが明らかです。その影響がどれほど大きいのか気になります。何倍も減るのでしょうか、それともわずか（10％以上）減っていくのでしょうか？
これと密接に関連するのは、同じ方法でmtimeを「バブリング」して、各ディレクトリのmtimeがサブツリー全体の最新の変更を反映するようにする概念です。たとえば、深くネストされたファイルが多いツリーでは、これら2つの機能を組み合わせて使用すると、rsyncモード速度を大幅に向上させることができます。--update
ベストアンサー1
最新のファイルシステム（例：zfs / btrfs / bcachefs）は実際には反対方向に進み、ファイル間の共有範囲を許可/奨励します。このように、「ディレクトリが占めるデータ量」の概念はあまり明確ではありません（これはハードリンクのためにすでにある程度真実であるにもかかわらず）。参照リンクを使用すると、明らかにより多くのデータを含むディレクトリを作成できます。ファイルシステムに適しています（少なくともdu理解ncduできる簡単なディスク分析ツールの場合）。質問を異なる方法で表現する1つの方法は、「このディレクトリが削除された場合、どのくらいの空き容量が確保されるのか」です。これはあまりあいまいではありませんが、スナップショットが作成されると、ほとんどのディレクトリには独自のサイズゼロがあるため、あまり役に立ちません。スナップショットでもデータにアクセスできます。
私もこの問題に直面しました：
- データ共有が可能なファイルシステムでは、スペース使用量を把握することは困難です。
- 大容量ファイルシステムでスペース使用量を分析するのに時間がかかりすぎる（I / O）
このために私は作成しましたBTDU、btrfsに関連するこれらの問題を解決するためにサンプリングされたディスク使用量アナライザ。
一般的な「バブル」の概念は次のとおりです。他のファイルシステムについてはわかりませんが、これは実際には他のツリーを再帰的に参照するタブルート（b-）ツリーを持つbtrfsが内部的に機能する方法と似ています。ツリー（さまざまなレベル）が更新されると、新しいコピーがディスク上の他の場所に書き込まれ（したがってbtrfsのCOW側）、親は新しいコピーを指すように更新されます。ルートツリーまで。 （実際には、この実装では不変性を維持しながら合理的なパフォーマンスを維持するために多くの最適化を使用しています。）