2014-04-07 13:42:39 +0000 2014-04-07 13:42:39 +0000
26
26

ファイルを削除してもディスク容量がいっぱいのまま

古いCentOS 5.6を使っていて、lvmを設定していない状態で、ルートファイルシステムが一杯になっています。

[root@tornms1 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 130G 124G 0 100% /
/dev/sdb1 264G 188M 250G 1% /data
/dev/sda1 99M 24M 71M 26% /boot
tmpfs 2.0G 0 2.0G 0% /dev/shm

[root@tornms1 ~]# mount
/dev/sda3 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sdb1 on /data type ext3 (rw)
/dev/sda1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)

次に何をすればいいのか、何かアイデアはありませんか? 残念ながら、現時点では箱を再起動することはできません。

回答 (9)

38
38
38
2014-04-07 14:02:13 +0000

ここでは2つのことが起こっているかもしれません。

最初に、ファイルシステムがrootにしか書けない領域を予約しています。これが、130Gのうち124Gが使用されているのに、使用可能な領域がゼロになっている理由です。おそらく、削除したファイルのせいで使用率がここまで下がったのでしょうが、通常のユーザーにとっては閾値以下ではありません。

これがあなたの状況で必死になっているのであれば、root のために予約されているスペースの量を変更することができるかもしれません。

# tune2fs -m 1 /dev/sda3

Second とコマンドを実行すると、オペレーティングシステムは、まだ開いている削除済みのファイルのディスク領域を解放しません。Apache のログファイルを削除した場合 (例えば)、空き領域を解放するために Apache を再起動する必要があります。

18
18
18
2015-09-24 09:32:08 +0000

プロセスが使用しているファイルを削除すると、lsでそのファイルが表示されなくなります。プロセスを停止するまで、プロセスはそのファイルに書き込みを続けています。

それらの削除されたファイルを表示するには、単にlsof|grep deleteを実行してください。

10
10
10
2014-04-07 21:03:43 +0000

ディスクがいっぱいです**問題を解決するための他の2つの方法:

1) マウントポイントの下に隠されている:linuxはマウントポイントの下にファイルが「隠されている」状態でディスクがいっぱいになっていることを表示します。ドライブにデータが書き込まれていて、その上に別のファイルシステムがマウントされてい る場合、マウントポイントの下にあるファイルが見えなくても、linux はディスクの使用量を正しく表示します。nfs をマウントしている場合は、それらをマウントしてみて、マウント前に誤ってそれらのディレクトリに何かが書き込まれていないかどうかを確認してください。

2) 破損したファイル:SMB経由でWindowsからlinuxへファイルを転送する際に時々見られます。1つのファイルがファイルディスクリプターを閉じるのに失敗し、4GBのゴミファイルになってしまいます。

これは、ファイルが入っているサブディレクトリを見つける必要があるので、修正するのはもっと面倒ですが、ファイル自体は簡単に削除できるので、修正は簡単です。私は du コマンドを使ってルートサブディレクトリのリストを作成し、ファイルスペースがどこで使われているかを調べます。

cd /
du -sh ./*

トップレベルのディレクトリの数は通常制限されているので、どのサブディレクトリがスペースを占有しているかを確認するために human readable フラグ -h を設定しています。

その後、問題のある子ディレクトリに cd して、その中の全ての項目について処理を繰り返します。大きなアイテムを簡単に発見できるようにするために、du を少し変更し、ソートと組み合わせています。

cd /<suspiciously large dir>
du -s ./* | sort -n

これは、すべてのファイルとディレクトリのバイトサイズによる最小から最大までの出力を生成します

4 ./bin 
462220 ./Documents
578899 ./Downloads
5788998769 ./Grocery List

オーバーサイズのファイルを見つけたら、通常はそのファイルを削除するだけです。

4
4
4
2014-04-07 14:27:52 +0000

どのファイルが開いているかは lsof で調べることができます。多くの出力を出すことができるので、以下の例ではlogで終わる行に限定しています。

# lsof | grep log$
rsyslogd 2109 syslog 0u unix 0xffff88022fa230c0 0t0 8894 /dev/log
rsyslogd 2109 syslog 1w REG 252,6 62393 26 /var/log/syslog
rsyslogd 2109 syslog 2w REG 252,6 113725 122 /var/log/auth.log
rsyslogd 2109 syslog 3u unix 0xffff88022fa23740 0t0 8921 /var/spool/postfix/dev/log
rsyslogd 2109 syslog 5w REG 252,6 65624 106 /var/log/mail.log
/usr/sbin 2129 root 2w REG 252,6 93602 38 /var/log/munin/munin-node.log
/usr/sbin 2129 root 4w REG 252,6 93602 38 /var/log/munin/munin-node.log
...
1
1
1
2017-06-08 10:02:04 +0000

いくつかのファイルが削除されても、いくつかのプロセスで使用されている場合、そのスペースは解放されません。この場合、そのファイルを使用しているプロセスを再起動するか、そのファイルを無効化してください。そのようなファイルを削除する代わりに無効化することは、常に良い習慣です。削除されたファイルを見つけるには、プロセス ID とファイルディスクリプタが表示されます。削除されたファイルをファイルディスクリプタで無効にするには

#lsof +L1
#echo "" > /proc/$pid/fd/$fd
1
1
1
2020-02-27 01:18:39 +0000

ほとんどの場合、ログファイルを削除すると ls でファイルを表示しなくなります。プロセスを停止するまで、プロセスはそのファイルに書き込んでいます。

1
1
1
2017-10-31 13:45:06 +0000

コマンド

#lsof +L1

と入力すると、削除された引用符でメモリを保持しているファイルのリストが表示されます。

ファイルの pid ( プロセス ID ) をメモする

プロセスを終了する

#kill <pid>

メモリはプロセスによって解放される

コマンドで確認する

#df -h
``` コマンドで確認する 

0x1& コマンドで確認する
0
0
0
2016-06-02 09:58:41 +0000

実際に観測された問題:

実際のファイルを削除しているのであって、ファイルへのsymlinksではないことを確認してください。特にログファイルの場合はそうなる可能性があります。

0
0
0
2016-01-23 08:00:36 +0000

これまで説明してきたことに加えて、削除されたファイルディレクトリのマウントポイントが、同じサーバー上の別のアタッチされたディスクデバイス上にある可能性があります。現在のマウントと fstab のエントリを確認してください。

関連する質問

6
10
5
37
9