小さなファイルシステムで非常に奇妙なファイルサイズ（600 PB以上）
XFSファイルシステムにサイズが約200 GBのファイルがありました。これは、KVM駆動の仮想マシンの仮想ディスクを含むQCOW2イメージでした。何かがうまくいかなかった（多分それはqemu-kvmのグリッチだったのかもしれませんが、よくわかりません）、仮想マシンがクラッシュし、今では次のようなファイルがあります：
191090708 -rwxr--r--. 1 root root 737571587400425984 Oct 10 10:03 973d10e0-a5e3-4a59-9f98-4b9b9f072ade
したがって、それはまだ191090708ブロックを占めていますが、lsは656ペタバイトと表示しています。
さらに、同じ前の履歴を持つ別のファイルがありますが、別のファイルシステム（XFSではなくGFS2）にあります。
410855320 -rwxr--r--. 1 root root 7493992262336241664 Dec 13 2014 ac2cb28f-09ac-4ca0-bde1-471e0c7276a0
それは410855320ブロックを占めますが、lsはそれを6.6エクサバイトとして示しています。
これらのファイルを削除しても安全ですか？ありがとうございました！
追伸定期的にスナップショットを撮るのはとても良いことです！ :)私は彼らなしでは何をするかわからない。
これらのファイルサイズが表示される理由は2つ考えられます。
- スパースファイル
- ファイルシステムの破損
スパースファイルは、一部のファイルシステムの機能であり、穴が開いたファイルを作成できます。穴に物理的なスペースは割り当てられません。ホール全体を読み取ると、NULバイトがすべて返されます。
表示されている理由がスパースファイルの場合は、非スパースファイルの場合と同じように削除しても安全です。
表示されている理由がファイルシステムの破損である場合、ファイルシステムチェックなしでファイルを削除するのは安全ではありません。複数のファイルが同じスペースを占有していると主張する方法でファイルシステムが破損している場合、いずれかのファイルを削除すると、それらのブロックが解放されます。これらの解放されたブロックが再利用されると、破損はさらに悪化します。
ファイルシステムが破損している可能性があると思われる他の症状が見られた場合は、ファイルを削除する前に、ファイルシステムを完全にチェックする必要があります。
ファイルシステムの破損を示唆する証拠がなく、ファイルがまばらに見える場合は、不要になったファイルを削除します。
問題は、ファイルサイズの計算方法です。
1つの方法は、最後のバイトのオフセット（lsなど）を調べることです。もう1つの方法は、実際に割り当てられたブロックを合計することです（duなど）。
おそらく非常に大きなオフセットで書き込まれたデータを持つファイルである場合に表示されるもの。ファイルアドレス空間の主要な部分が割り当てられていないことを意味します。しかし、あなたはまだそれを読むことができます。