
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は13GBと表示されるのでしょうかそれとも何か見逃しているのでしょうか?
完全な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
-h
human_autoscale | human_SI | human_base_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.2g しかないかもしれませんが (これは正しいです)、物理ディスクでは 13gb のスペースを占有する場合があります。これは、「ブロッキング「そしてそれは断片化の結果です。
ウィキペディア: ファイルの長さはブロック サイズの整数倍ではないことが多く、そのためファイルの最後のブロックが部分的に空のままになるため、内部の断片化によりスペースの非効率が生じます。これにより、ファイルごとに平均半ブロックのスラック スペースが作成されます。新しいファイル システムの中には、ブロック サブ割り当てとテール マージと呼ばれる手法を使用してこの問題を解決しようとするものもあります。
編集:
man ページには次のように書かれています:
SIZE は、次のいずれかになります(またはオプションで整数が後に続く場合もあります)。kB 1000、K 1024、MB 1000*1000、M 1024*1024 など、G、T、P、E、Z、Y の場合も同様です。
ということは、M ではなく MB が使用されている可能性があるので、12.796 と表示され、おそらく 13 に丸められると考えられます。
答え3
マルチテラバイトのファイルシステムに関する最近の経験では、「df -h」のスケーリングがわかりにくいことがあります。「合計サイズ」列は整数に丸められ、常に切り上げられるのに対し、「使用済み」および「使用可能」列はスケーリングされ、小数点第 1 位に丸められるためです。これにより、合計サイズが実際よりもほぼ 1 単位大きく表示されることがあります。サイズが MB、GB、TB などの小さな数値である場合に、その影響が最も顕著になります。