ファイルを削除しますが、ディスク容量はまだいっぱいです

古いCentOS 5.6ボックスを処理し、LVMセットアップなしで、ルートファイルシステム/がいっぱいになり、不要な多くの古いログファイルとアプリケーションファイルをクリアしました。サイズは2〜5GB以上でしたが、システムそれでもディスクがいっぱいであることを報告します。

[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)

次に何をしようとするべきかについてのアイデアはありますか？残念ながら、現時点ではボックスを再起動することはできません。

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

まず、ファイルシステムはroot書き込み専用の領域を確保しているため、通常のユーザーがディスク領域を使い果たしても重要なシステムプロセスが失敗することはありません。130Gのうち124Gが使用されていますが、ゼロが使用可能になっているのはそのためです。おそらく、削除したファイルによって使用率はこのポイントまで下がりましたが、通常のユーザーのしきい値を下回っていません。

これがあなたの状況であり、あなたが必死なら、あなたは予約されrootたスペースの量を変えることができるかもしれません。1％（デフォルトは5％）に減らすには、コマンドは次のようになります。

# tune2fs -m 1 /dev/sda3

第二に、オペレーティングシステムは、まだ開いている削除済みファイルのディスク領域を解放しません。（たとえば）Apacheのログファイルの1つを削除した場合、スペースを解放するためにApacheを再起動する必要があります。

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

削除されたファイルを表示するには、単に実行します lsof|grep delete

ディスクを取得する他の2つの方法は完全な問題です。

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

2）ファイルの破損： SMBを介したWindowsからLinuxへのファイル転送で、これが時々表示されます。1つのファイルがファイル記述子のクローズに失敗すると、4GBのゴミファイルが作成されます。

ファイルのあるサブディレクトリを見つける必要があるため、これは修正するのが面倒ですが、ファイル自体は簡単に削除できるので簡単に修正できます。duコマンドを使用し、ルートサブディレクトリのリストを作成して、ファイルスペースが使用されている場所を見つけます。

cd /
du -sh ./* 

通常、最上位ディレクトリの数は制限されているため、人間が読めるフラグを設定して、-hどのサブディレクトリがスペースホグかを確認します。

次に、問題のある子にcdし、その中のすべてのアイテムに対してプロセスを繰り返します。大きなアイテムを見つけやすくするために、duを少し変更して、並べ替えます。

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

これにより、すべてのファイルとディレクトリのバイトサイズごとに最小から最大の出力が生成されます。

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

特大のファイルを見つけたら、通常は削除するだけです。

どのファイルが開いているかはlsofで確認できます。多くの出力が生成される可能性があるため、以下の例では、ログで終わる行に限定しました。

# 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
...

いくつかのファイルが削除されても、何らかのプロセスで使用されている場合、そのスペースは解放されません。この場合、ファイルを使用しているプロセスを再起動するか、ファイルを無効にします。そのようなファイルを削除するのではなく、nullにすることを常にお勧めします。削除されたファイルを見つけるが、まだ何らかのプロセスで使用されている

#lsof +L1

プロセスIDとファイル記述子を提供します。ファイル記述子によって削除されたファイルをnullにするには

#echo "" > /proc/$pid/fd/$fd 

コマンドを入力します

#lsof +L1

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

ファイルのpid（プロセスID）に注意してください

プロセスを強制終了する

#kill <pid>

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

コマンドで確認する

#df -h

説明されていることに加えて、問題は、同じサーバー上の別の接続されたディスクデバイス上の削除されたファイルディレクトリの別のマウントポイントがあることです。現在のマウントとfstabエントリを確認します。

実際に観察された実際の問題：

ファイルへのシンボリックリンクではなく、実際のファイルを削除していることを確認してください。これは、特にログファイルに当てはまります。