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


0

如果我列出了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表演

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


coreutils您安装了哪个版本的?请考虑同时打印df显示单位的标题行。
丹尼尔·贝克

@DanielBeck我已经添加了df的完整输出,并且我正在使用ubuntu 10.04,如何检查coreutils版本?
Anurag Uniyal 2012年

@DanielBeck coreutils 7.4
Anurag Uniyal 2012年

Answers:


2

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),导致使用1024作为单位增量自动缩放并打印SI样式后缀,即),并且该值不是整数:-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;
}

0

通常,这与格式化系统的效率低下有关。例如,一个文件可能只有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。


它不是文件,而是设备本身+为什么为什么kb和mb值也不会显示相同的东西,即使对于文件.8 GB额外:)也是荒谬的
Anurag Uniyal 2012年

更新后,似乎没有一个很好的答案。但是,根据所使用的方法(他们提出了两种方案可以使用),它会轮12或13
nerdwaller

0

我最近在多TB文件系统中的经验是,'df -h'的缩放可能会引起混淆,因为'total size'列四舍五入为整数,并且始终向上取整,而'used'和'available'列缩放并四舍五入到小数点后一位。这样可以使总大小几乎比整个“单位”大。当大小很小(MB,GB或TB)时,效果最为明显。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.