Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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

If I list df output for KB, MB and GB, they do not match e.g.

$ df -k |grep xvdb
/dev/xvdb1            12796048    732812  11413172   7% /xxx
$ df -m |grep xvdb
/dev/xvdb1               12497       716     11146   7% /xxx
$ df -h |grep xvdb
/dev/xvdb1             13G  716M   11G   7% /xxx
  • 12796048 KB = 12496.14 MB so that is slight off but OK
  • 12796048 KB = 12.2 GB, 12407 MB is also 12.2 GB

so why df is showing 13 GB or am I missing something?

Here is full df listing

$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/xvda1            7.5G  1.7G  5.5G  24% /
none                  5.8G  128K  5.8G   1% /dev
none                  5.8G     0  5.8G   0% /dev/shm
none                  5.8G   44K  5.8G   1% /var/run
none                  5.8G     0  5.8G   0% /var/lock
none                  5.8G     0  5.8G   0% /lib/init/rw
/dev/xvdb1             13G  716M   11G   6% /xxx

Coreutils version seems to 7.4 as info coreutils shows

This manual documents version 7.4 of the GNU core utilities,

share|improve this question
What version of coreutils do you have installed? Consider printing the header line of df as well, which shows the units. – Daniel Beck Nov 2 '12 at 16:53
@DanielBeck I have added df full output and I am using ubuntu 10.04, how to check coreutils version? – Anurag Uniyal Nov 2 '12 at 17:00
@DanielBeck coreutils 7.4 – Anurag Uniyal Nov 2 '12 at 17:05

df always rounds up human readable output (-h and -H).

From its source code in the coreutils package, lib/human.h, an enum of options for the human_readable function providing rounding, unit converting, etc.:

/* Options for human_readable.  */
  /* Unless otherwise specified these options may be ORed together.  */

  /* The following three options are mutually exclusive.  */
  /* Round to plus infinity (default).  */
  human_ceiling = 0,
  /* Round to nearest, ties to even.  */
  human_round_to_nearest = 1,
  /* Round to minus infinity.  */
  human_floor = 2,

Note the comment: Round to plus infinity (default).

The actual rounding likely happens in the following function in human.c, which adds true (i.e. 1) if no other rounding option shown above is set (it isn't, -h only sets human_autoscale | human_SI | human_base_1024, resulting in automatic scaling using 1024 as unit increment and printing the SI style suffix, i.e. G) and the value isn't an integer:

static long double
adjust_value (int inexact_style, long double value)
  /* Do not use the floorl or ceill functions, as that would mean
     checking for their presence and possibly linking with the
     standard math library, which is a porting pain.  So leave the
     value alone if it is too large to easily round.  */
  if (inexact_style != human_round_to_nearest && value < UINTMAX_MAX)
      uintmax_t u = value;
      value = u + (inexact_style == human_ceiling && u != value);

  return value;
share|improve this answer

Typically that is associated with inefficiencies of a formatting system. For example, a file may only be 12.2g (which you are correct on) but on the physical disc it may take up 13gb of space. That's due to "blocking" and is a result of fragmentation.

Wikipedia: This leads to space inefficiency due to internal fragmentation, since file lengths are often not integer multiples of block size, and thus the last block of files will remain partially empty. This will create slack space, which averages half a block per file. Some newer file systems attempt to solve this through techniques called block suballocation and tail merging.


The man page says this:

SIZE may be (or may be an integer optionally followed by) one of fol- lowing: kB 1000, K 1024, MB 1000*1000, M 1024*1024, and so on for G, T, P, E, Z, Y.

That leads me to believe that it may be using MB instead of M, so that would show 12.796 - rounding to 13 perhaps.

share|improve this answer
it is not a file it is a device itself + why would then kb and mb values wouldn't show same thing, even for file .8 GB extra :) is ridiculous – Anurag Uniyal Nov 2 '12 at 16:09
Updated, there doesn't seem to be a great answer out there. But depending on the method used (they suggest two the program may use) it'll round to 12 or 13. – nerdwaller Nov 2 '12 at 16:17

My recent experience with multi-terabyte filesystems, is that the scaling in 'df -h' can be confusing, because the 'total size' column is rounded to an integer, and always up, while the 'used' and 'available' columns are scaled and rounded to 1 decimal place. This can make total size show as almost a whole 'unit' bigger than it is. The effect is most obvious when the size is such that you are in small numbers - whether MB, GB or TB.

share|improve this answer

Your Answer


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.