ディスクがいっぱいです、duは別のことを伝えます。さらに調査する方法は？
サーバー（ハードウェアRaid 1）、32G、ext3ファイルシステムにSCSIディスクがあります。 dfは、ディスクが100％使用されていることを示しています。 1Gを削除すると、正しく表示されます。
ただし、du -h -x /次にduは、12Gのみが使用されていることを通知します（私は-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)
その後、Apache（_service httpd restart_）を再起動して状況を解決し、削除されたファイルのロックを解除できるようにして、2GBのディスク領域をクリアしました。
私は、OldTrollの回答があなたの「欠落」スペースの最も可能性の高い原因であることに同意します。
Linuxでは、ルートパーティション全体（またはそのほかのパーティション）をファイルシステムの別の場所に簡単に再マウントできます。たとえば、/ mntと言うだけで、
mount -o bind / /mnt
その後、あなたはすることができます
du -h /mnt
何があなたのスペースを使い果たしているかを見てください。
追記：コメントではなく新しい回答を追加して申し訳ありませんが、この投稿を読みやすくするために書式を設定する必要がありました。
何を見るdf -iは言います。 iノードが不足している可能性があります。これは、ファイルシステムに多数の小さなファイルがあり、使用可能なスペースをすべて消費することなく、使用可能なiノードをすべて使い果たした場合に発生する可能性があります。
私の場合、これは大きな削除されたファイルに関係していました。このページを見つける前に解決するのはかなり大変でした。
最後に、lsof | grep deletedを使用して問題を解決しました。これにより、2つの非常に大きなログファイル（使用可能な8GBルートパーティションの合計5GB）を保持しているプログラムがわかりました。
プログラムによって開かれているファイルは、削除しても実際には消えません（ディスク領域の消費を停止します）のではなく、プログラムがファイルを閉じると消えます。プログラムには、あなた（とdu）が見ることのできない巨大な一時ファイルがある場合があります。ゾンビプログラムの場合は、これらのファイルをクリアするために再起動が必要になる場合があります。
これを試して、ディスクへの書き込み中にデッド/ハングしたプロセスがロックされているかどうかを確認します。 grep "/ mnt"
次に、スタックしているPIDをすべて削除してみます（特に、「（削除済み）」で終わる行を探します）。
私にとっては、Sudo duの下に大量のdockerファイルがあり、Sudo以外のユーザーが読み取る権限を持っていないため、/var/lib/dockerを実行する必要がありました。
これは、大きなファイルを見つけるためにこれまでに見つけた最も簡単な方法です。
ルートマウントがフルの場合の例を次に示します/（mount/root）例：
cd /（ルートにいるので）
ls | xargs du -hs
出力例：
9.4Mビン 63Mブート 4.0K cgroup 680K dev 31Mなど 6.3Gホーム 313M lib 32M lib64 16K lost + found 61Gメディア 4.0K mnt 113M opt du：アクセスできません ` proc/6102/task/6102/fd/4 '：そのようなファイルまたはディレクトリはありません 0 proc 19M root 840K run 19M sbin 4.0K selinux 4.0K srv 25Gストア 26M tmp
次にstoreが大きいことに気づくでしょうcd/store
そして再び走る
ls | xargs du -hs
出力例： 109Mバックアップ 358M fnb 4.0G iso 8.0K ks 16K lost + found 47M root 11Mスクリプト 79M tmp 21G vms
この場合、vmsディレクトリはスペースの独占です。
したがって、Centos 7でもこの問題があり、bleachbitのようなものをたくさん試し、/ usrと/ varをそれぞれ7Gしか表示しなかったとしても、それらをクリーニングした後に解決策を見つけました。ルートパーティションで使用されている50Gのうち50Gがまだ表示されていましたが、9Gのファイル使用量しか表示されませんでした。ライブubuntu cdを実行し、問題のある50Gパーティションをアンマウントし、ターミナルを開いて、パーティションでxfs_checkおよびxfs_repairを実行しました。次にパーティションを再マウントすると、lost + foundディレクトリが40Gに拡張されました。 lost + foundをサイズでソートし、最終的にmp3エラーを繰り返したSteamの38Gテキストログファイルを見つけました。大きなファイルを削除してスペースを確保すると、ディスクの使用量がルートパーティションのサイズと一致します。 Steamログが再び大きくならないようにする方法を知りたいです。
考慮すべきもう1つの可能性-dockerを使用していて、ボリュームマウントを使用しているコンテナー内でdf/duを実行している場合、大きな不一致が必ず発生することがほぼ確実です。 Dockerホスト上のボリュームにマウントされたディレクトリの場合、dfはホストのdfの合計を報告します。これは考えれば明らかですが、「ディスクがいっぱいのコンテナが暴走した！」というレポートが表示された場合は、du -hs <dir>のようなものでコンテナのファイルスペース使用量を確認してください。
私の場合、lsofは役に立ちませんでした。 losetupをループデバイスとして使用してディスクイメージをマウントしたため、これを追跡することができました。これらのデバイスをアンマウントして対応するイメージを削除した後でも、ディスクイメージへの間接参照のようなものを維持するプロセスがありました。
つまり、Sudo ps -ef|grep loop、次にSudo losetup -d /dev/loopX。これはduとdfが同意しない理由への直接の回答ではありませんが、私が見つけることができる回答とは異なる理由を最終的に理解することができたので、十分に頻繁に思い付きました。
このトピックで言及されているのと同じ問題がありましたが、1つのVPSにありました。そのため、このトピックで説明されているすべてをテストしましたが、成功しませんでした。この解決策は、割り当ての再計算を実行し、df -hとdu-sh /のスペースの違いを修正したVPSプロバイダーのサポートへの連絡先でした。
今日、私はFreeBSDボックスでこの問題に遭遇しました。問題は、それがviのアーティファクトであることでした（vimではなく、vimがこの問題を引き起こすかどうかは不明です）。ファイルはスペースを消費していましたが、完全にディスクに書き込まれていませんでした。
あなたはそれをチェックすることができます：
_$ fstat -f /path/to/mount/point |sort -nk8 |tail
_これは、開いているすべてのファイルを調べ、8番目の列（キー、_-n_）で（数値的に_-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 -_
これらは、viewの代わりに_vim -R_を使用します。これは、vimがインストールされると、ほとんどの場合...代わりに、それらをviewまたは_vi -R_にパイプしてお気軽に。
このような大きなファイルを開いて実際に編集する場合は、sed、awk、またはその他のプログラムによるアプローチを検討してください。
サーバーにossecエージェントがインストールされているかどうかを確認してください。または、削除されたログファイルを使用しているプロセスがあります。私の昔はossecエージェントでした。
本番環境でも同様のことが起こり、ディスク使用率は98％に達しました。次の調査を行いました：
a）df -i inodeの使用状況を確認するため、inodeの使用率は6％でしたので、ファイルのサイズはそれほど大きくありません
b）rootのマウントと隠しファイルの確認。 追加ファイルをファイルできませんでした。 du結果はマウント前と同じでした。
c）最後に、nginxlogsを確認しました。ディスクに書き込むように構成されていましたが、開発者がログファイルを直接削除したため、nginxはすべてのログをメモリに保持していました。ファイルとして/var/log/nginx/access.logはrmを使用してディスクから削除されましたが、duを使用しても表示されませんでしたが、ファイルはnginxによってアクセスされていたため、まだ保持されていましたopen =
マウントされたディスクがWindowsマシンの共有フォルダである場合、dfはWindowsディスク全体のサイズとディスク使用量を表示するようですが、duはアクセスできるディスクの一部のみを表示します。 （およびマウントされています）。したがって、この場合、問題はWindowsマシンで修正する必要があります。