解決策 1:
ローカル サーバーで問題を追跡しようとしているときに、このページにたどり着きました。
私の場合、 df -h と du -sh ハードディスク サイズの約 50% が一致しません。
これは、apache (httpd) が、ディスクから削除された大きなログ ファイルをメモリに保持していることが原因でした。
これは lsof | grep "/var" | grep deleted を実行することで追跡されました どこで /var クリーンアップが必要なパーティションでした。
出力には次のような行が表示されました。
httpd 32617 nobody 106w REG 9,4 1835222944 688166 /var/log/apache/awstats_log (deleted)
この状況は、Apache を再起動することで解決されました (service httpd restart )、削除されたファイルのロックをクリアできるようにすることで、2GB のディスク容量をクリアしました。
解決策 2:
マウント ポイントの下にあるファイルを確認します。多くの場合、ディレクトリ (sambafs など) を、その下に既にファイルまたはディレクトリがあるファイルシステムにマウントすると、それらのファイルを表示できなくなりますが、基盤となるディスクのスペースは引き続き消費されます。シングル ユーザー モードでファイルのコピーを、シングル ユーザー モード以外では見ることができないディレクトリにダンプしたことがあります (他のディレクトリ システムがその上にマウントされているため)。
解決策 3:
「不足している」スペースの最も可能性の高い原因として、OldTroll の回答に同意します。
Linux では、ルート パーティション全体 (またはその他のパーティション) をファイル システムの別の場所 (たとえば /mnt など) に簡単に再マウントできます。
mount -o bind / /mnt
du -h /mnt
何がスペースを使用しているかを確認してください。
Ps:コメントではなく新しい回答を追加して申し訳ありませんが、この投稿を読みやすくするために書式設定が必要でした。
解決策 4:
df -i を参照してください と言う。 inode が不足している可能性があります。これは、そのファイル システムに多数の小さなファイルがあり、利用可能なスペースをすべて消費することなく、利用可能なすべての inode を使い果たしてしまう場合に発生する可能性があります。
解決策 5:
私の場合、これは大きな削除済みファイルに関係していました。このページにたどり着く前に解決するのはかなり苦労しましたが、正しい道にたどり着きました.
lsof | grep deleted を使用して最終的に問題を解決しました 、どのプログラムが 2 つの非常に大きなログ ファイルを保持していたかを示しました (使用可能な 8 GB のルート パーティションの合計 5 GB になります)。