web-dev-qa-db-ja.com

linux-ディスク容量がありません

# df -h /
Filesystem            Size  Used Avail Use% Mounted on
rootfs                9.9G  7.2G  2.2G  77% /

# du -hx --max-depth=0 /
3.2G    /

ご覧のとおり、dfは7.2GBが使用されていると言いますが、duは3.2GBしか見つけられません。これに気付いてからサーバーが再起動されたため、削除されたファイルではありません。さらに、lsofには、興味深いものは何も表示されません。他に何ができるでしょうか？

linuxhard-drivedisk-space-utilization
6
wes

私は自分のext4システムでまったく同じ問題を抱えていたので、将来の参考のために自分のソリューションを投稿したかっただけです。ドライブが最初にいっぱいになったとき、/ var/logから大量のログを削除しました。これで数GBがクリアされましたが、数日以内に再びスペースが足りなくなり、du -hと「mount --bind// mnt」が原因を指摘できなくなりました。ついに手に入れたのは、私がlsofを実行したときです。

 lsof 
 ... 
 rsyslogd 1766 root 2w REG 9,1 12672375940 264014/var/log/messages（deleted）
 ...

メッセージログファイルを削除したとき、rsyslogサービスは開いたままでしたが、非表示でした。 「touch/var/log/messages; service rsyslog restart」を実行すると問題が解決し、ディスク領域が解放されました。

Lsofの出力は、特にシステムがビジーな場合（私のシステムでは1000行を超えていた場合）、少し圧倒される可能性があります。 lsofの出力で "deleted"をgrepすると、問題のプロセスを特定するのに役立ちます。

12
John P

-xオプション、他のファイルシステムがマウントされていると思いますか？空ではないディレクトリの上に別のパーティションがマウントされている可能性があります。

6
DerfK

マウントポイントの「背後」にあるすべてのフォルダーが空であることを確認してください。経験上、おそらくマウントポイントの背後にあるデータを隠していると思います。

ディスク/パーティションをアンマウントすることなく、マウントポイントの後ろにあるフォルダーの内容を確認できます（たとえば、/ usrをアンマウントする必要がある場合は、Niceになります）。ただ

# mount --bind / /mnt
# du -shx /mnt

補足として：

# du -shx /

あなたのduと同じことをしますが、かなり短いです（-sは要約を表します）

5
Marcel G

いくつかの問題が発生する可能性があります：（1）プロセスが削除した大きなファイルまたは多数のファイルを開いている、または（2）ドライブのfsckによって修正されたある種のファイルシステムの問題がある可能性があります。ただし、これはドライブがマウントされていない場合にのみ実行できます。いくつかのLinuxは、ブート時にルートファイルを完全fsckする方法を次の方法で提供しています。

 touch /forcefsck

その後再起動します。これはSuSEとRedHatの亜種に存在することを知っています。

4
mdpc