Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I had a file on an XFS filesystem which size was about 200 GB. It was a QCOW2 image containing a virtual disk of a KVM-driven virtual machine. Something went wrong (maybe it was some glitch of qemu-kvm, I'm not sure), the virtual machine had crashed and now I have a file that looks like that:

191090708 -rwxr--r--. 1 root root 737571587400425984 Oct 10 10:03 973d10e0-a5e3-4a59-9f98-4b9b9f072ade

So, it still occupies 191090708 blocks, but ls shows it as 656 petabytes.

Moreover, I have another file with the same pre-history, but on another filesystem (not XFS, but GFS2):

410855320 -rwxr--r--. 1 root root 7493992262336241664 Dec 13  2014 ac2cb28f-09ac-4ca0-bde1-471e0c7276a0

It occupies 410855320 blocks, but ls shows it as ~6.6 exabytes.

What do you think, is it safe to remove these files? Thank you!

P.S. It's so good to have snapshots taken on a regular basis! :) I don't know what I would do without them.

share|improve this question
    
Thank you very much for your replies. Of course, I know about sparse files, but the most important question for me is the following: is it safe to remove these files? As I see now, there is a chance to lose some data if the filesystems are corrupted. I can't be sure that the filesystems are okay, because it's undesirable to unmount & check them, but the first occurence had happened 4 months ago, the second - 14 months ago, so I hope that I would see that there were any filesystem corruption if there were any. What do you think? – Vladimir Melnik Feb 12 at 14:21

I can see two possible reasons for you to be seeing those file sizes:

  • Sparse files
  • File system corruption

Sparse files is a feature on some file systems whereby you can create a file with holes in it. No physical space is allocated for the holes. Reading across the holes will return NUL bytes all the way.

If the reason for what you are seeing is sparse files, then it is as safe to delete them as it would be with a non-sparse file.

If the reason for what you are seeing is file system corruption, then it is not safe to delete the files without a file system check. If a file system is corrupted in a way where multiple files claim to be occupying the same space, then deleting either file would cause those blocks to be freed. Once those freed blocks are reused the corruption gets worse.

If you have seen any other symptoms making you think the file system may be corrupted, you should force a full check of the file system before deleting the files.

If there is no evidence suggesting the file system is corrupted, and the files appear to be sparse, I would just delete the files once I don't need them any longer.

share|improve this answer

The problem is the way you compute a file size.

One way it is look the offset of the last byte (like ls). The other way is to sum really allocated blocks (like du).

What you see if probably a file with data written at very large offset. Meaning that major parts of your file address space is not allocated. But you can still read it.

share|improve this answer
    
Thank you. What do you think, won't it crash anything if I just remove these files? – Vladimir Melnik Feb 10 at 12:55
1  
Google "sparse file" for details. – Kondybas Feb 10 at 13:20

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.