私はdfが94%/フルを報告するファイルサーバーを持っています。しかし、duによれば、はるかに少ないものが使用されます:
# df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 270G 240G 17G 94% /
# du -hxs /
124G /
開いているが削除されたファイルが原因である可能性があることを読みましたが、再起動してもこれは修正されませんでした。
これはLinux、ext3です。
よろしく
わかりました。
/ mnt/Backup 同じファイルシステム内に古いバックアップがあり、その場所に外部ドライブがマウントされていました。そのため、duはファイルを見ませんでした。これをクリーンアップすると、ディスクスペースが戻ってきました。
これはおそらくこのように発生しました。毎日のバックアップスクリプトの実行中に、外付けドライブが一度アンマウントされました。
このリンク が原因である可能性のあるすべての理由について、より完全な説明が見つかるとは思いません。役立つかもしれないいくつかのハイライト:
ものを台無しにする可能性があるほぼ100%である場合、inodeの使用法は何ですか?
df -i
あなたのブロックサイズは何ですか?たくさんの小さなファイルと大きなブロックサイズはそれをかなり歪めるかもしれません。
Sudo tune2fs -l/dev/sda1 | grep「ブロックサイズ」
ファイルを削除し、これを調査したと言いましたが、合計スペースを取得するには、次のパイプラインを使用できます(lsofは解析が面倒なので、lsofの代わりにfindが好きです)。
Sudoは/ proc/*/fd -printf "%l\t%s\n"を見つけます| grepが削除されました|カット-f2 | (tr '\ n' +;エコー0)|紀元前
しかし、それはほぼ2倍オフです。安全のため、マウント解除されているパーティションでfsckを実行します。
プロセスがまだ開いている間にファイルが削除されるケースのようです。この切断が発生するのは、duコマンドがファイルシステムに存在するファイルのスペースを合計し、dfがファイルシステムで使用可能なブロックを表示するためです。開いて削除されたファイルのブロックは、そのファイルが閉じられるまで解放されません。
/ procを調べると、どのプロセスが開いているが削除されたファイルを見つけることができます
find /proc/*/fd -ls | grep deleted
あなたのケースで最も可能性の高い理由は、非常に小さい(ドライブ上のブロックサイズよりも小さい)ファイルがたくさんあることです。その場合、dfはすべての使用済みブロックの合計を報告しますが、duはファイルサイズの実際の合計を報告します。
私はそれに賛成だ
lsof +L 1 /home | grep -i deleted
開始するのに良い場所です。私の場合、実行されているPerlスクリプトがたくさんあり、削除されたはずのファイルがたくさんあることに気づきました。
私はPerl関数を強制終了しました。これにより、du
とdf
はほぼ同じになり、ケースはクローズされました。
デフォルトでは、ファイルシステムをEXT3でフォーマットすると、ドライブの5%がルート用に予約されます。 dfは、利用可能なものを報告するときにこの予約を考慮に入れますが、duは実際に使用されているものを示します。
次のコマンドを実行して、予約されたブロックを表示できます。
tune2fs -l/dev/sda | grep -i reserve
そしてあなたは次のようなものを得るでしょう:
Reserved block count: 412825
Reserved GDT blocks: 1022
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
それをより低いパーセントに調整したい場合は、次のようなものでそれを行うことができます
tune2fs -m 1/dev/sda
あなたはそれを0に減らすことができます、しかしこれはあなたのルートファイルシステムなので、私はそれをすることに警戒するでしょう。ファイルシステムが実際にいっぱいになった場合、それをクリーンアップするために必要なメンテナンスタスクが困難になる可能性があります。
Duがディレクトリのサイズも追加しない可能性はありますか?それでも、大きな違いのように思えますが、それがすべての原因になるわけではありません。