ディスクがいっぱいです、duは異なることを示します。さらに調査する方法は？

サーバー（ハードウェアRAID 1）、32G、ext3ファイルシステムにSCSIディスクがあります。dfディスクが100％いっぱいであることを教えてくれます。1Gを削除すると、これが正しく表示されます。

ただし、aを実行するとdu -h -x /、du12Gのみが使用されていることがわかります（-x一部のSambaマウントのために使用します）。

だから私の質問は、duコマンドとdfコマンドの微妙な違いではなく、この大きな違いの原因をどうやって見つけることができるのかということです。

エラーなしでfsckのためにマシンをリブートしました。走るべきbadblocks？lsof開いている削除済みファイルlost+foundは表示されず、空であり、メッセージファイルに明らかなwarn / err / failステートメントはありません。

セットアップの詳細についてはお気軽にお問い合わせください。

マウントポイントの下にあるファイルを確認します。多くの場合、すでにファイル（またはディレクトリ）が存在するファイルシステムにディレクトリ（たとえばsambafs）をマウントすると、それらのファイルを表示する機能が失われますが、それらは基礎となるディスクのスペースを消費しています。シングルユーザーモードでファイルをコピーしましたが、シングルユーザーモード以外のディレクトリにファイルをダンプしました（他のディレクトリシステムがマウントされているため）。

ローカルサーバー上の問題を追跡しようとしたときに、このページで偶然見つけました。

私の場合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)

その後service httpd restart、apache（）を再起動して状況を解決し、削除されたファイルのロックをクリアできるようにして、2GBのディスク容量をクリアしました。

OldTrollの回答が、「不足」スペースの最も可能性の高い原因であることに同意します。

Linuxでは、ルートパーティション全体（またはその他のパーティション）をファイルシステム内の別の場所、たとえば/ mntに簡単に再マウントできます。たとえば、

mount -o bind / /mnt

その後、あなたはすることができます

du -h /mnt

そして何があなたのスペースを使い果たしているかを見てください。

追伸：コメントではなく新しい回答を追加して申し訳ありませんが、この投稿を読みやすくするには書式が必要でした。

df -i言うことを参照してください。iノードが不足している可能性があります。これは、そのファイルシステムに多数の小さなファイルが存在する場合に発生する可能性があります。

私の場合、これは削除された大きなファイルに関係していました。このページを見つける前に解決するのはかなりつらかったので、正しい道に進みました。

最後にlsof | grep deleted、を使用して問題を解決しました。これにより、2つの非常に大きなログファイル（合計で使用可能な8 GBのルートパーティションのうち5 GB）を保持しているプログラムがわかりました。

プログラムによって開かれているファイルは、削除しても実際には消えません（ディスク容量の消費を停止します）。プログラムが閉じたときに消えます。プログラムには、あなた（とdu）が見ることのできない巨大な一時ファイルがあるかもしれません。ゾンビプログラムの場合、これらのファイルをクリアするには再起動が必要になる場合があります。

これを試して、ディスクへの書き込み中にデッド/ハングプロセスがロックされているかどうかを確認します。grep "/ mnt"

次に、スタックしているPIDをすべて削除してみてください（特に「（deleted）」で終わる行を探してください）

これは、私がこれまでに見つけた最も大きな方法で大きなファイルを見つける方法です！

ルートマウントがfull /（mount / root）の場合の例を次に示します。例：

cd /（あなたがルートにいるので）

ls | xargs du -hs

出力例：

 9.4Mビン
 63Mブート
 4.0K cgroup
 680K開発
 31Mなど
 6.3Gホーム
 313M lib
 32M lib64
 16K失われた+見つかった
 61Gメディア
 4.0K mnt
 113Mオプション
 du： `proc / 6102 / task / 6102 / fd / 4 'にアクセスできません：そのようなファイルまたはディレクトリはありません
 0 proc
 19Mルート
 840Kラン
 19Mスビン
 4.0K selinux
 4.0K srv
 25Gストア
 26M tmp

その後、ストアが大きい ことに気付くでしょうcd / store

そして再び走る

ls | xargs du -hs

出力例： 
 109Mバックアップ
 358M fnb
 4.0G iso
 8.0K ks
 16K失われた+見つかった
 47Mルート
 11Mスクリプト
 79M tmp
 21G VM

この場合、vmsディレクトリはスペースホグです。

私にとっては、非sudoユーザーが読み取り権限を持っていないsudo du下に大量のdockerファイルがあったので実行する必要がありました/var/lib/docker。

考慮すべきもう1つの可能性-Dockerを使用し、ボリュームマウントを使用しているコンテナ内でdf / duを実行すると、大きな不一致がほぼ確実に発生します。Dockerホスト上のボリュームにマウントされたディレクトリの場合、dfはHOSTのdf合計を報告します。考えてみればこれは明らかですが、「ディスクがいっぱいになった暴走コンテナ！」というレポートを受け取ったときは、コンテナのファイルスペースの消費量をのようなもので確認してくださいdu -hs <dir>。

したがって、Centos 7でもこの問題が発生し、それぞれが約7Gしか表示されていなくても、bleachbitや/ usrと/ varのクリーニングなどを試して解決策を見つけました。ルートパーティションで使用されている50Gのうち50Gがまだ表示されていましたが、9Gのファイル使用量しか表示されていませんでした。ライブのubuntu cdを実行し、問題のある50Gパーティションをアンマウントし、ターミナルを開き、パーティションでxfs_checkとxfs_repairを実行しました。その後、パーティションを再マウントすると、lost + foundディレクトリが40Gに拡張されました。lost + foundをサイズでソートし、最終的にmp3エラーを繰り返したSteamの38Gテキストログファイルを見つけました。大きなファイルを削除してスペースを確保し、ディスクの使用量がルートパーティションのサイズと一致するようにしました。蒸気ログが再び大きくならないようにする方法を知りたい。

マウントされたディスクがWindowsマシン上の共有フォルダーである場合、dfはWindowsディスク全体のサイズとディスク使用量を表示するように見えますが、duはアクセスできるディスクの一部のみを表示します。（およびマウントされます）。この場合、Windowsマシンで問題を修正する必要があります。

本番環境でも同様のことが起こり、ディスク使用量は98％に達しました。次の調査を行いました：

a）df -iinodeの使用状況を確認するため、inodeの使用状況は6％だったので、それほど小さいファイルではありませんでした

b）root隠しファイルのマウントとチェック。余分なファイルをファイルできませんでした。du結果はマウント前と同じでした。

c）最後に、nginxログを確認しました。ディスクに書き込むように構成されていましたが、開発者がログファイルを直接削除nginxしたため、すべてのログがメモリ内に保持されていました。ファイル/var/log/nginx/access.logを使用しrmてディスクから削除されたため、ファイルを使用して表示されませんでしたduが、ファイルにアクセスされnginxていたため、開いたままでした

このトピックで言及されているのと同じ問題を抱えていましたが、1つのVPSで発生しました。そのため、このトピックで説明されているすべてをテストしましたが、成功していません。ソリューションは、クォータの再計算を行い、スペースの差を補正し、当社のVPSのプロバイダとサポートのための接触だったdf -hとdu-sh /。

今日、FreeBSDのボックスでこの問題に遭遇しました。問題は、それがvi（この問題を引き起こすvimかどうかわからない）のアーティファクトであったことでしたvim。ファイルはスペースを消費していましたが、ディスクに完全に書き込まれていませんでした。

以下で確認できます：

$ fstat -f /path/to/mount/point |sort -nk8 |tail

これは、開いているすべてのファイルを調べ-n、8番目の列（キー、-k8）で並べ替え（数値でを介して）、最後の10項目を表示します。

私の場合、最後の（最大の）エントリは次のようになりました。

bob      vi         12345    4 /var      97267 -rwx------  1569454080 rw

これは、プロセス（PID）12345がdu気づいていないにもかかわらず、1.46G（8列目を1024³で割った値）のディスクを消費していたことを意味していました。 vi非常に大きなファイルを表示するのは恐ろしいです。100MBでも大きいです。1.5G（または実際にそのファイルがどれだけ大きいか）はばかげています。

解決策はそれでしたsudo kill -HUP 12345（それがうまくいかなかった場合、私はそうsudo kill 12345し、それも失敗した場合、恐ろしいものkill -9が出てくるでしょう）。

大きなファイルにはテキストエディターを使用しないでください。迅速なスキミングの回避策の例：

合理的なライン長を想定：

• { head -n1000 big.log; tail -n1000 big.log } |vim -R -
• wc -l big.log |awk -v n=2000 'NR==FNR{L=$1;next}FNR%int(L/n)==1' - big.log |vim -R -

不当に大きな線を想定：

• { head -c8000 big.log; tail -c8000 big.log } |vim -R -

これらの使用vim -Rの代わりに、view理由はvimそれがインストールされていますとき...ほとんど常により良いです。パイプを代わりに、viewまたはvi -R代わりにパイプしてください。

あなたが実際にそれを編集するには、このような大きなファイルを開いている場合は、考えるsedか、awkまたはいくつかの他のプログラム的なアプローチ。

サーバーにossecエージェントがインストールされているかどうかを確認してください。または、一部のプロセスが削除されたログファイルを使用しています。私の昔はossecエージェントでした。

/ lost + foundを確認してください。システム（centos 7）があり、/ lost + foundのファイルの一部がすべてのスペースを使い果たしました。