ext4ルートファイルシステム（存在する場合はVMWare ESX仮想マシンのCentos 7.1のllvmの下）に数GBがありません。
[someone@somewhere ~]$ sudo du -xsm /
4561 /
しかし：
[someone@somewhere ~]$ sudo df -m /
Filesystem 1M-blocks Used Available Use% Mounted on
/dev/mapper/vg_sys-lv_root 8944 7562 956 89% /
マウントポイントの下に何かがあるかもしれないと思って、次のことを試しました。
[someone@somewhere ~]$ sudo mount --bind / /vp
[someone@somewhere ~]$ sudo du -xsm /vp
4561 /vp
削除されたファイルがまだプロセスで使用されている可能性があります。
sudo lsof | grep deleted
重要な内容は表示されません。
スパースファイルを見つけるためにrootとして次のコマンドを使用することは機能しません（見つかったコマンドはここ):
find / -type f ! -size 0 -exec perl -le 'for(@ARGV){open(A,"<",$_)or next;seek A,0,4;$p=tell A;seek A,0,2;print if$p!=tell A;close A}' {} +
もしそうなら、私のデータは他の場所にあるかもしれません。また、df -iを確認しましたが、半分未満のinodeが使用されています。
答え1
他の可能な説明：
- または、mount名前空間にあり、
chrootファイルシステム全体へのアクセス権がありません。 /mount 名前空間にない場合は、ls -id /どちらを実行して確認できます。2chroot - ファイルシステムが破損しています。
- このスペースは、次のいずれかが使用しています。特殊インデックスノード。検証のために
debugfssomestat <3>、...を使用して発行できますstat <4>。 - そのスペースは、他のpid名前空間のプロセスによって開かれた削除されたファイルによって使用されています（そしてルートpid名前空間にはありません）。
- どのファイルでも開かれませんが、たとえば、確認のためにループデバイスに接続されている削除されたファイルはスペースを使用しています
losetup -a。
スパースファイルはduとdf。
答え2
ファイルシステムは、ファイルの内容に関係のないさまざまな操作にディスク容量を使用できます。
df使用されるブロックと使用可能なブロックの数はファイルシステムから直接取得され、du単に各ファイルに割り当てられたブロックのサイズを加算するため、無関係なFSデータ構造は考慮されません。
du実際よりも少ないスペースを表示するのはまったく問題ありませんdf。特に、ほとんど変更されないルートパーティションの場合、違いが大きすぎるのは奇妙です。 FSを調整しましたか？ともdu --inodes比較してみましたdf -iか？