At the end of last week one of my colleagues noticed something strange on one of our shared compute servers.

We have a directory which ls -l shows as containing a file which is 132G in size.

However, running df -h shows that the total amount of space used on the disk as 128G. Additionally running du -h --max-depth=1 on the root of the drive also reports 128G for .

Initially I wondered whether this issue might be as a result of open file handles or similar causing these binaries to report different information. However, I have tired unmounting and remounting the disk and all binaries report the same results as before.

To give a bit more information on the configuration of the drive:

  • The volume is formatted using EXT4 on top of LUKS encryption.
  • The disk is not shared via NFS or similar.
  • I have check the file in question and it does not appear to be linked.
  • When unmounting and remounting the volume I forced a disk check, by running fsck -f on the volume, and no issues were returned.
  • The server the disk is located on isn't a virtualisation host and is running Ubuntu 14.04 as the OS.

1 Answer 1


Is your server virtualization host?

Different real file and disk space size is normal behaviour for dynamically expanding virtual disks. This disks has different real file size and header filesize data


possibly you use qemu virtual disks (qcow2 extension or other) which you can find with:

find / -regex '.*\.qcow.*$'


Lets check vm-105-disk-1.qcow2 size with stat:

stat vm-105-disk-1.qcow2

  File: vm-100-disk-1.qcow2
  Size: 68745560064

79728541696 - is approxymately 64GB

Check with wc:

wc -c <vm-105-disk-1.qcow2


The same result... Check with du:

du -sh vm-105-disk-1.qcow2

15G        vm-105-disk-1.qcow2

Only 15GB! Lets check with qemu-img util:

qemu-img info vm-105-disk-1.qcow2

image: vm-105-disk-1.qcow2
file format: qcow2
virtual size: 64G (68719476736 bytes)
disk size: 14G
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

Pay attention at this two lines and everything should be clear:

virtual size: 64G (68719476736 bytes)
disk size: 14G

If your server is not virtualization host, see this topics:

  • Thanks @Egor! That's good to know. Unfortunately the sever in question isn't a virtualisation host, instead the OS is running on the bare hardware. I'll add update my post to make that clearer. Nov 23, 2017 at 11:19
  • @PicoutputCls, i added the answer, see above Nov 23, 2017 at 11:36
  • Thanks @EgorVasilyev for the update! It turns out the issue I was having is related to sparse files, as explained fully in the last of those three links: Why ls and du show different size? Adding --apparent-size to du makes everything consistent. Nov 23, 2017 at 12:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .