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,如果沒有設定上面顯示的其他舍入選項(它不是,僅設定),則添加true(即) ,導致使用1024 作為單位增量自動縮放並列印SI 樣式後綴,即) 且該值不是整數: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」中的縮放可能會令人困惑,因為「總大小」列四捨五入為整數,並且始終向上,而「已使用」和「可用」列被縮放並四捨五入到小數點後一位。這可以使總尺寸顯示為比實際更大的幾乎整個“單位”。當大小較小時(無論是 MB、GB 或 TB),效果最為明顯。

相關內容