ディスク容量の使用量がdfとduにならない

私はディスクスペースをいくらかdf -h空けようとしています-もしそうなら、/ dev / mapper / vg00-varというファイルシステムがあり、4G、3.8Gが使用され、205Mが残っています。

それは私の/ varディレクトリに対応します。

/ varに降りてdo du -kscxh *すると、合計は2.1Gです

2.1G + 200M無料= 2.3G ...だから私の質問は、残りの1.7Gはどこですか？

linux du df

何てdu -shx /var言うの？

— カイルスミス

ファイルハンドルが開いているファイルを削除することもできます。OSは、ハンドルが閉じられるまでスペースを解放しませんが、「du」では表示されません。「lsof / var | grep deleted」（または同様のもの）を実行して、それらを確認できます。ログはローテーションされているが、ロギングプロセスが正しい方法でHUPされていない場合、これは実際には、たとえば/ var / logで驚くべき発見ではありません。

— cjc

私は狂ったログファイルをいくつか削除していましたが、回転していないように見えましたが、とにかく友人から「リブート」という一言のメールがありました-彼は皮肉であると思われましたが、明らかにそうではありません:)再び私のディスクスペースを見つけました。...（今のところ）災害は回避されました。

— コードクラフト

@Codecraftええ、再起動すると開いているファイルハンドルはすべてクリアされますが、それはハンマーで卵を割るようなものです。

— cjc

@cjcヨーキーの良さを得る限り...！卵を打つことなく、開いているファイルハンドルをクリアする方法に関する提案はありますか？

— コードクラフト

おそらく、削除された大きなログファイル、データベースファイル、またはそれに類するものがいくつかあり、ファイルを保持しているプロセスがそれを解放するのを待っています。

Linuxでは、ファイルを削除すると、ファイルのリンクが解除されます。そのファイルに接続されているファイルハンドルがなくなると、実際に削除されます。したがって、rmを使用して手動で削除する2 GBのログファイルがある場合、syslogデーモンを再起動する（またはHUP信号を送信する）までディスク領域は解放されません。

試してみる

lsof -n | grep -i deleted

削除されたゾンビファイルがまだ残っているかどうかを確認します。

— ジャンヌ・ピッカライネン
ソース

私はあなたのコマンドを実行することができませんでしたが、あなたが言ったことは強打されたように見えました-私は手動でいくつかのログを失ったクレイジーを殺していました、そして最終的に、再起動はディスクスペースを再計算して正しく表示しました

— コードクラフト

Apacheログが/ var / log / apache /ディレクトリをいっぱいにしてくれたので、うまくいきました。したがって、サーバー全体を再起動する必要はなく、syslogを再起動する必要はないかもしれません。上記のコマンドの出力で見つかるサービスだけです。

— イヴァン14

これは私たちだけでした。tomcat6 catalina.outがlogrotateに捕まらないようにしました。4Gbに達したときに削除してlogrotateを修正しました。数週間後、4Gbが戻ってこなかった理由を知りました。そのlsofコマンドは、削除を保留している多くのTomcatファイルがあることを示しました。tomcatを再起動すると、突然大量のスペースが戻ってきました！

— ニック

最後に私のために働いた答え。PostgreSQLはクラッシュし、1TiBディスク上のリンクされていないファイルの400GiB（!!!）への接続を開いたままにしました。Postgresを再起動すると修正されました。

— 須藤