これ通常ディレクトリサイズを取得する方法は次のとおりです。
du -hs /path/to/directory
しかし、うまくいかず、これはbtrfsの問題であると思われます。サブモジュールを含むサブディレクトリのサイズがディスク自体の合計サイズを超えることが報告されました。
ただし、gnomeディスクユーティリティを使用して、ディスクが60％以上空であることを確認できます。
さらなるn検査を通して
du -h --max-depth=n /path/to/folder
大きなサブディレクトリサイズをbtrfsサブボリュームに減らすことができたので、問題はサブボリュームに関連していると思います。
ベストアンサー1
はい、BTRFS関連の問題かもしれません。
一般に、クラシックはduBTRFSに対して信頼できず、しばしばこのようにとんでもないような結果を提供します。これは、最終的にシステムコール（各ファイルがディスク上でどのくらいのスペースを使用しているかを判断するために使用されます）が、リンク、スナップショット、透過圧縮、またはstat()BTRFSによって提供されるdu標準のPOSIXセマンティクス以外の参照を知らない、または気にしないためです。です。
これにより、du参照リンクを介してファイル間で共有されるすべてのブロックが計算されます（ここには、重複排除されたすべてのブロック、複製ioctlを使用してファイルをコピーした結果、共有ブロック、およびスナップショットの一部であるすべてのブロックが含まれます）。ファイルごとこれはブロックへの参照を保持し、du実際のスペース使用量よりはるかに大きい明白なディスク使用量を示すことができます。
すべての共有スペースの使用量を正確に計算するため、代わりにbtrfs filesystem du使用することをお勧めします。du
また、GNOMEディスクユーティリティはdfBTRFSを処理するときに完全に信頼できませんが、他の理由で信頼できません（参照リンクは正しく考慮されますが、BTRFSで使用されている2段階のアロケータを理解していないため、実際にディスクを移動できます）。 major）は何も書けない場合でも空です）。したがって、duファイルシステムのルートで実行されたものとは異なる使用値を表示することがよくあります。 （du -xマウントポイントのように見えるため、サブボリュームの境界を拡張しないため、使用すると状況がさらに悪化します。）