web-dev-qa-db-ja.com

空きディスク容量がありません

Linuxのdfコマンドで空きディスク領域がないと表示されるので、私は奇妙な状況にあります

[root@backup cache]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda3              72G   70G     0 100% /
/dev/sda1             190M   11M  170M   7% /boot
tmpfs                 248M     0  248M   0% /dev/shm

だが du -sh /*言います

[root@backup cache]# du -sh /*
4.0K    /bacula-restores
7.4M    /bin
5.4M    /boot
3.6T    /data
116K    /dev
55M     /etc
204K    /home
76M     /lib
16K     /lost+found
12K     /media
0       /misc
16K     /mnt
8.0K    /mount
0       /net
8.0K    /opt
0       /proc
2.3G    /root
32M     /sbin
8.0K    /selinux
168K    /share
8.0K    /srv
0       /sys
361M    /test
20K     /tmp
3.2G    /usr
1.5G    /var

どこに問題があるのか​​教えてもらえますか？私のスペースはどこですか？私はそれを理解することができません:(

linuxdisk-space-utilization
10
skomak

試してください：

$ lsof +L1

これにより、リンク数が1未満のファイルが見つかります（ファイルは削除されていますが、まだ書き込まれています）。

Duとdfが一致しないときのために。

27
rkthkr

ショートバージョン：lsofを使用して、リンクされていないがまだ開いているファイルを見つけます。ファイルを保持しているアプリケーション（または怠惰な場合はシステム全体）を再起動すると、空き領域が元に戻ります。

ロングバージョン：ほとんどの場合、アプリケーションによって開かれ、書き込まれているが、ファイルシステムからリンク解除（削除）されたファイルがあります。

NTFSとは異なり、extには一種の参照カウントがあります。つまり、ファイルを削除すると、そのファイルへの参照が削除されます。プログラムでファイルを開くと、参照が追加されます。したがって、どのプログラムがファイルを保持しているかを把握する必要があります。これが、UNIXでのファイル操作に関して、リンク/リンク解除への参照がよく見られる理由です。通常、ファイルの検索はlsofツールを使用して行われます。

この動作の良い面は、Windowsでよくある「ファイルが開いているため削除できない」というエラーが発生しないことです。共有ライブラリなどのシステムファイルを置き換えることもできます。ソフトウェアは、ソフトウェアのアップグレード（Windowsの場合）のために再起動する代わりに、再起動（およびディスクから新しいライブラリをロード）するまで、古いライブラリを使用します。あなたが今目にする悪い面。ファイルシステム内の可視ファイルのサイズは、通常、ディスク上のデータ量と一致しません。

9
pehrs

または、この場合の貧乏人lsofは（Linuxの場合）

ls -l /proc/*/fd/ | grep deleted
6
Dan Andreatta

アンマウントされている間は、常に空のディレクトリで「chattr + i/mount-point」を実行します。

マウントされていないときに何かが書き込もうとすると、「アクセスが拒否されました」というエラーメッセージが返されます。そして、あなたはすぐにエラーに気づきます。

「/ mount-point」に適切にマウントされたリソースがある場合、「chattr + i」は効果がなく、すべてが期待どおりに機能します。

4
famzah

iノードが使い果たされていないかどうかを確認することもできます。 df -i。

3
Jmarki

ドライブ上のファイルが比較的小さい場合もまったく同じ問題がありましたが、ディスク領域が100％使用されていました。バックアップドライブの同期を実行した後、プライマリブートディスクがいっぱいになるという問題がありました。

>rsync -avxHAXW /media/backup1 /media/backup2

この同期後、プライマリディスクがいっぱいになりました。バックアップではなく、誤ってブートディスクにファイルをコピーしていたことがわかりました2。私は間違いを修正し、プライマリディスク上の大容量ファイルを削除して、rsyncを再実行しました。バックアップディスクをアンマウントして再マウントした後でも、ブートディスクの容量が不足していました。起動ディスクの大きなファイルをクリーンアップしてみました...

>find . -type f -print0 | xargs -0 du -s | sort -n | tail -25 | cut -f2 | xargs -I{} du -sh {}

不要になった大きなファイルを削除しました。ゴミ箱も必ず空にしました。

>empty-trash

その作業のすべての後...ディスクはまだいっぱいです。マシンを再起動することにしました。再起動後、ブートディスクパーティションが100％から10％になりました。 rsyncプロセスは、ディスクリソースを保持しているバックグラウンドで実行し続けている必要があります。

私はこのアドバイスをするのは嫌いですが、すべてのディスククリーンアップを実行した後、マシンを再起動して、データに掛かっているバックグラウンドプロセスを停止して、ディスクが本当に解放されないようにする必要がある場合があります。

1
Steve Scherer

何が悪かったのか知っています。 NFSを/ dataとしてマウントし、NFSがネットワークエラー接続を取得し、/ dataがNFS共有ではなく/としてマウントされたディスク上にあった。

このようなメカニズムに関係しているのではないかと思いました

dirリストの例：//a [dir] file1 file2/b [dir]

別のデバイス：/ fileX fileY

「別のデバイス」を/ aにマウントすると、/ aディレクトリを介してこのデバイスにアクセスできますが、元の/ aはまだ存在していますが、オーバーハンドルされます。最後にマウントされたデバイスをアンマウントした後、元のディレクトリにアクセスできます。それは興味深い特性ですが、実際にはいくつかの問題を引き起こす可能性があります（現時点では私のものではありません）。

1
skomak
  • ルートの予約スペースを減らしてみてくださいtune2fs
  • 別のマシンからネットワークを監視して、隠れた悪質なプロセスがマシンをwarezトラフィックのサーバーとして使用しているかどうかを確認します
  • モノリシックカーネルを使用している場合、それを使って再起動すると、LKMルートキットが無効になります（存在する場合）
  • rkhunter、chkrootkitを実行します。
  • ライブディストリビューションで再起動し、RAMからディスクを分析します
0
drAlberT

すでに提案されている原因に加えて、次の原因も考えられます。

  • 別のディスクが、データでいっぱいの既存のフォルダーの上にマウントされます
  • duはマウントされたディスクの消費サイズを計算し、dfは実際に消費されたサイズを表示します
  • 解決策：（可能な場合）すべての非ルートディスクをマウント解除し、du -md 1でサイズを再度確認します。 hiddenフォルダーを別の場所に移動するか、別の場所にマウントして、状況を修正します。
0
Robert Lujo