☰

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

tag-icon • tag-icon ubuntu-10.04 coreutils df
df -h показывает неправильный вывод в ГБ

Если я перечислю вывод df для КБ, МБ и ГБ, они не совпадают, например

$ 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 КБ = 12496,14 МБ, так что это немного не так, но нормально
  • 12796048 КБ = 12,2 ГБ, 12407 МБ также 12,2 ГБ

так почему df показывает 13 ГБили я что-то упускаю?

Вот полный список df

$ 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, похоже, 7.4, как info coreutilsпоказано

В этом руководстве описывается версия 7.4 основных утилит GNU,

решение1

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 в качестве приращения единицы и печати суффикса стиля СИ, т.е. 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;
}

решение2

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

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

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

На странице руководства написано следующее:

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

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

решение3

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

Связанный контент