df -h showing wrong output in GB

Question

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,

Answer 1

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.  */
enum
{
  /* 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;
}

Answer 2

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.

Edit:

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.

Answer 3

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.