1

I wanted to check my filesystem backup size

ls -lia backup.tgz 
17 -rw-r--r-- 1 root root 84972633333 мај 28 10:05 backup.tgz

With block-size M

 ls -l --block-size=M backup.tgz 
-rw-r--r-- 1 root root 81037M мај 28 10:05 backup.tgz

Finally with block-size G

ls -l --block-size=G backup.tgz 
-rw-r--r-- 1 root root 80G мај 28 10:05 backup.tgz

Could someone explain such a huge difference?

5

The values are shown using powers of 2, not powers of 10; so 1M is 1,048,576 bytes, and 1G is 1,073,741,824 bytes.

If you divide accordingly, the values match the ls output (rounded up):

$ echo $((84972633333.0/1024/1024))
81036.218007087708

$ echo $((84972633333.0/1024/1024/1024))
79.136931647546589

You can specify KB, MB, GB etc. instead to use powers of 10:

ls -l --block-size=MB backup.tgz

See the section on block sizes in the coreutils documentation for details.

4
  • and there are also rounding (errors) involved. Usually it rounds down instead of up, and it can be quite disconcerting to see 0GB in an output. May 28 '19 at 10:18
  • 1
    @Rui do you still have examples of file sizes being rounded down? On my systems, even a 1-byte file shows up as 1G. The docs say “Fractional block counts are rounded up to the nearest integer.” and that matches my experience. May 28 '19 at 11:03
  • There are two different implementations of df afair. I had problems both with rounding down and having two different df implementations on a wrapper script for automating netbackup installation/upgrade operations recently. Had to use MB instead of GB to get around that. May 28 '19 at 11:06
  • Ah, right, df; I was thinking about ls (as per the question). df also rounds up which is unfortunate since it overestimates the available space... (For a script though I’d use byte sizes.) May 28 '19 at 11:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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