我在 XFS 文件系统上有一个文件，大小约为 200 GB。这是一个 QCOW2 映像，包含 KVM 驱动的虚拟机的虚拟磁盘。出了点问题（可能是 qemu-kvm 的一些故障，我不确定），虚拟机崩溃了，现在我有一个如下所示的文件：
191090708 -rwxr--r--. 1 root root 737571587400425984 Oct 10 10:03 973d10e0-a5e3-4a59-9f98-4b9b9f072ade
因此，它仍然占用 191090708 个块，但ls显示为 656 PB。
此外，我还有另一个具有相同历史记录的文件，但位于另一个文件系统上（不是 XFS，而是 GFS2）：
410855320 -rwxr--r--. 1 root root 7493992262336241664 Dec 13 2014 ac2cb28f-09ac-4ca0-bde1-471e0c7276a0
它占用了 410855320 个块，但ls显示为~6.6 EB。
您觉得删除这些文件安全吗？谢谢！
PS 定期拍摄快照真是太好了！:) 我不知道如果没有它们我该怎么办。
答案1
我认为您看到这些文件大小有两个可能的原因：
- 稀疏文件
- 文件系统损坏
稀疏文件是某些文件系统的一项功能，通过此功能您可以创建一个带有空洞的文件。没有为空洞分配物理空间。跨空洞读取将始终返回 NUL 字节。
如果您看到的情况是由于稀疏文件，那么删除它们与删除非稀疏文件一样安全。
如果您看到的情况是文件系统损坏造成的，那么在未检查文件系统的情况下删除文件是不安全的。如果文件系统损坏，多个文件声称占用同一空间，则删除任一文件都会导致释放这些块。一旦重新使用这些释放的块，损坏就会变得更严重。
如果您发现任何其他症状让您认为文件系统可能已损坏，则应在删除文件之前强制对文件系统进行全面检查。
如果没有证据表明文件系统已损坏，并且文件看起来很稀疏，那么当我不再需要这些文件时我就会删除它们。
答案2
问题在于您计算文件大小的方式。
一种方法是查看最后一个字节的偏移量（例如 ls）。另一种方法是计算实际分配的块总数（例如 du）。
您看到的可能是文件的数据写入偏移量非常大。这意味着文件地址空间的大部分尚未分配。但您仍然可以读取它。