df -h показывает неправильный вывод в ГБ

df всегда округляет читабельный вывод (-h а также -H).

Из его исходного кода в пакете coreutils, lib/human.hПеречень вариантов для human_readable функции, обеспечивающие округление, преобразование единиц и т. д.:

/* 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,
...

Обратите внимание на комментарий: Round to plus infinity (default).

Фактическое округление, вероятно, происходит в следующей функции в human.c, который добавляет true (т.е. 1) если никакая другая опция округления, показанная выше, не установлена ​​(это не так, -h только наборы human_autoscale | human_SI | human_base_1024, что приводит к автоматическому масштабированию с использованием 1024 в качестве приращения единицы и печати суффикса стиля SI, т.е. G) и значение не является целым числом:

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;
}

Мой недавний опыт работы с многотерабайтными файловыми системами заключается в том, что масштабирование в 'df -h' может сбивать с толку, потому что столбец 'total size' округляется до целого числа и всегда вверх, тогда как столбцы 'used' и 'available' масштабируются и округляются до 1 знака после запятой. Это может привести к тому, что общий размер увеличится почти на целую единицу. Эффект наиболее очевиден, когда размер таков, что вы находитесь в небольших количествах - будь то МБ, ГБ или ТБ.

Как правило, это связано с неэффективностью системы форматирования. Например, размер файла может составлять всего 12,2 г (на котором вы правы), но на физическом диске он может занимать 13 ГБ. Это связано с " блокировкой" и является результатом фрагментации.

Википедия: Это приводит к неэффективности пространства из-за внутренней фрагментации, поскольку длины файлов часто не являются целыми числами, кратными размеру блока, и, таким образом, последний блок файлов будет оставаться частично пустым. Это создаст свободное пространство, которое в среднем составляет половину блока на файл. Некоторые новые файловые системы пытаются решить эту проблему с помощью методов, называемых перераспределением блоков и хвостовым слиянием.

Редактировать:

Страница руководства говорит это:

РАЗМЕР может быть (или может быть целым числом, за которым может следовать) один из следующих: кБ 1000, К 1024, МБ 1000*1000, М 1024*1024 и т. Д. Для G, T, P, E, Z, Y,

Это наводит меня на мысль, что он может использовать MB вместо M, так что будет показано 12.796 - округление до 13, возможно.