☰

なぜ[df]はディスクがいっぱいだと言いますが、root [du]は5TBのうち約500GBしか満たしていないと言いますか？

tag-icon • tag-icon raspberry-pi filesystems disk-usage
なぜ[df]はディスクがいっぱいだと言いますが、root [du]は5TBのうち約500GBしか満たしていないと言いますか？

FUSEファイルシステムには新しい5TBディスクがありますが、デフォルトでは空のようですが、dfはそうではありません。ディスク上のファイルシステムは、mergerfs4つの5TB Seagate 5400rpm外付けハードドライブで構成され、すべて1つのパーティションにext4フォーマットされていますfdisk。ルートに入り、duで確認してみると約500GBのスペースが使われたそうです。

pi@raspberrypi:~ $ df -h /mnt/hdd/disk4
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1       4.6T  4.3T  393M 100% /mnt/hdd/disk4

root@raspberrypi:~# du -sh /mnt/hdd/disk4
464G    /mnt/hdd/disk4

誰でもこの問題を解決するのに役立ちますか？

ベストアンサー1

これは私が以前に経験したことですが、私の経験では極端なケースです。これは通常、ディスクから削除されたファイルがあるため報告されませんが、du実行中のプロセスのどこかにまだ開いている場合に発生するため、df使用されるスペースを考慮してください。最も一般的な「犯人」は、ログロテートがロギングプロセスを正しく再起動しないため、次のような結果になります。

  • ディスクに表示されるログファイルは、書き込まれたり書き込まれたりしない場合があります。
  • ログ書き込みプロセスはアクティブログファイル（例：）app.logと前日のログファイル（たとえば2022-01-03-app.log、今日が2022-01-04の場合）に（おそらく）書き込まれていますが、前日のファイルはありますls（例2022-01-03-app.log.gz：）。
  • 解凍すると、前日のログファイルは多くのスペース（数十GB）を占めます。

この特定の例では、logrotateデーモンは真夜中に前日のログファイルを回転させ、前日のタイムスタンプを提供しますが、プロセスに記録しても実際にログの再起動をトリガーしません。前日のログファイルを圧縮した後、圧縮されていないファイルを削除しますが、書き込み中にファイルハンドルがまだ開いているため、スペースがすでに占有されているとdf見なされます。

この問題は通常、logrotate構成ファイルに（SIGHUP）タイプディレクティブを追加することで解決できますが、まれにHUPHUPに正しく応答しないため、問題のあるプロセスを実際に再起動する必要があります。

このような場合、問題のあるプロセスを見つけて再起動すると、報告された使用スペースがdf突然急激に減少し、df出力がdu一致します。

おすすめ記事