2

I'm a little confused. With ls -laght a file with the size 1,0T is displayed:

-rw------- 1 nogroup 1,0T May 6 14:01 nextcloud-flat.vmdk

with ncdu only 9,1 GB:

/mnt/backup/backup/nextcloud/nextcloud-2019-05-06_11-23-12
9.1 GiB [###########] nextcloud-flat.vmdk

What's the real truth now? Background: A VMWare backup with ghettoVCB was made to an NFS server. The parameter is set that ghettoVCB converts the vmdk files into a 'flat'.

Melebius
  • 11,121
  • 8
  • 50
  • 77

1 Answers1

1

In general there are three things to consider:

1) Different rounding rules 2) Possibly using GB (1000^3) vs. GiB (1024^3) 3) du reports the actual space used, when ls reports the size of the file

But in this case, you have a lot larger file when running ls than when running du, what should not happen for regular files.

As it is a lot larger (1 TB vs. 9.1 GB), it may be a sparse file that may grow up to 1 TB but only uses 9.1 GB, yet.

allo
  • 651
  • 3
  • 9
  • _“You're most likely seeing different rounding rules.”_ Wouldn’t 9.1 GiB get rounded to zero when rounding to terabytes (which would still mean a bug in the human-readable size format)? – Melebius May 07 '19 at 08:25
  • in other words: both commands show different scales; one logical- and one physical size of the file. (see: https://stackoverflow.com/questions/31437198/what-is-the-most-reliable-command-to-find-actual-size-of-a-file-linux). In fact, the VMWare Esxi-Datastore browser shows me a file size of 9.08 GB (provisioned 'thin'-vmdk format) and nextcloud can be started from the backup. – Christian Koderer May 07 '19 at 11:37
  • 1
    Sorry, I misread the 1TB as 10 GB. So this seems to be something totally different. It might be a sparse file. I added it to my answer. – allo May 07 '19 at 11:48
  • It is interesting how a vmdk-specific topic is correctly interpreted by the linux file system... how the reservation of the sparse file is interpreted. Will try the same on an NTFS file system. What is also quite exciting is that the vmdk restore from the Ubuntu NFS actually costs 10.18 GB on the internal restore datastore (SSD hard disk) and not the full disk space of 1.0 T as expected or 9.08 GB as predicted by linux (probably related to the VMWare file system, cluster size). And last but not least thanks for the clarification and the right hint. – Christian Koderer May 07 '19 at 13:54