df -h 显示 GB 中的错误输出

df -h 显示 GB 中的错误输出

如果我列出 KB、MB 和 GB 的 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 KB = 12496.14 MB 稍微有点偏差,但还可以
  • 12796048 KB = 12.2 GB,12407 MB 也是 12.2 GB

那么为什么 df 显示 13 GB或者我遗漏了什么?

以下是完整的 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所示

本手册记录了 GNU 核心实用程序 7.4 版,

答案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,如果未设置上面显示的其他舍入选项(未设置,仅设置,导致使用 1024 作为单位增量自动缩放并打印 SI 样式后缀,即true) ,则该函数添加(即)并且该值不是整数:1-hhuman_autoscale | human_SI | human_base_1024G

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.2g(您说的没错),但在物理磁盘上它可能占用 13gb 的空间。这是因为“阻塞“这是碎片化的结果。

维基百科:这会导致由于内部碎片而导致空间效率低下,因为文件长度通常不是块大小的整数倍,因此文件的最后一个块将保持部分为空。这将创建松弛空间,平均每个文件半个块。一些较新的文件系统尝试通过称为块子分配和尾部合并的技术来解决这个问题。

编辑

手册页是这样说的:

SIZE 可能是(或者可能是可选后跟的整数)下列之一:kB 1000、K 1024、MB 1000*1000、M 1024*1024,等等(对于 G、T、P、E、Z、Y)。

这使我相信它可能使用 MB 而不是 M,因此会显示 12.796 - 也许四舍五入为 13。

答案3

我最近使用多 TB 文件系统的经验是,“df -h”中的缩放可能会令人困惑,因为“总大小”列四舍五入为整数,并且始终向上,而“已用”和“可用”列则缩放并四舍五入到小数点后 1 位。这会使总大小显示为比实际大几乎一个“单位”。当大小为小数时(无论是 MB、GB 还是 TB),这种影响最为明显。

相关内容