KiB を GiB に変換

1 キビバイトはちょうど 1,024 バイトです。この名前は 1998 年に、「キロバイト」に 1,000 の意味を返してやるために導入されました。もっとも、定着したとは言いがたい状況です。

1 ギビバイトは 1,073,741,824 バイトで、ギガバイトより 7 % ほど大きい値です。Windows はギビバイトで測りながら、それを「GB」と表示します。「容量が足りない気がする」という疑問のからくりは、まるごとこれです。

こちら向きの計算は割り算で、しかも整数で割り切れます。1,048,576 単位が余りなく ギビバイト 1 つに収まります。不便なのは、結果が分数で出てくることだけです——3 分の 1、12 分の 1——逆向きなら得られる、きりのよい整数の代わりに。

それでも丸めで失われるものはありません。割り算が割り切れるからです。結果が小数で収まらない場合——0.0833… のような——それは分数が顔を出しているのであって、誤差が入り込んでいるのではありません。

KiB 1 つはひとつ下の単位の 1,024 倍で、kB 1 つは 1,000 倍です。このページでは 0 GiB と 0 GiB の差——2.4 %——になり、段を上がるごとにこの隔たりは開いていきます。写真 1 枚では丸め誤差でしかないものが、ハードディスクでは目に見える割合になるのはそのためです。

「容量が消えた」という話の中身は、これだけです。kB で売られたディスクには、書いてあるとおりのバイト数が入っています。それを 1,000 ではなく 1,024 で割り、名前は kB のまま表示しているのが Windows です。macOS は 10.6 以降ディスクの容量を十進の単位で数えているので、同じディスクが 2 台のパソコンで違う大きさに見えることがあります。減ったものはなく、丸めているのでもありません。同じバイト数に、名前が 2 つあるだけです。

/proc/meminfoのあらゆる値は1,024バイト単位のカウントであり、kBというラベルが付けられています。/proc/swapsや/sys配下のノードごとのmeminfoファイル、メモリ関連のsysctlも同様です。このラベルはキビバイトという単位に名前が付くよりも前から存在していて、今から変更すればこのファイルを解析してきたあらゆるスクリプトが壊れてしまうため、間違ったまま残されており、プログラムでこれを読む人は誰もが無視の仕方を知っています。

手作業で換算する人にとっての帰結は、最初の段階で2.4パーセント、ギビバイトに達するまでに7.4パーセントの誤差が、マシンを実際より小さく見せる方向に生じるということです。MemTotalの16,316,480を100万で割ると「16.3 GB」ですが、1,048,576で割ると15.56 GiBになり、後者のほうがマシン上の他のあらゆるツールが報告する値と一致します。

ハードディスクでは10進の数字がメーカーのもので、二進の数字がOSのもので、どちらがより正しいというわけでもありません。同じバイトを数える二つの方法です。メモリはそうではありません。メモリアレイはアドレス線で選択されます。n本のアドレス線が2のn乗個の位置を選ぶので、それ以外の容量ならアドレス空間の一部が何も選択しないまま残ってしまうため、容量は2のべき乗に落ち着きます。

これが8 GiBを8 GBモジュールの真の容量にしています——8,589,934,592バイトで、10進のラベルのほうが近似値です。これがメモリの容量とストレージの同じ名目容量が同じバイト数を意味しない理由であり、キビバイトのメモリカウントをGiBに換算するときりの良い数字になり、ディスクの数字を換算してもほとんどそうならない理由でもあります。

この差は本物で、しかも謎ではなく内訳があります。ファームウェアは1 MiB未満とACPIテーブル周辺の領域を予約し、統合グラフィックスはノートパソコンでは1ギビバイトにも達する固定分を確保し、カーネルイメージとページテーブル、マシン自体のメモリマップはMemTotalが計算される前に上前を取っていきます。dmesg | grep -i memoryでブート時の予約が見られます。

16 GiBのノートパソコンが15.56 GiBと報告しているなら、およそ450 MiB、460,736 KiB分が失われたことになり、「どこに消えたのか」という質問には合計ではなくその差分を換算するほうが役に立ちます。ECCメモリを搭載したサーバーはさらに8分の1をチェックビット用に失いますが、その割合はカーネルには見えず、キビバイトの数字にはまったく現れません。

この比率は1,048,576で、100万に十分近いため、下六桁を落とすと5パーセント以内の見積もりが得られます。MemTotal 32,633,240 KiBは「約32.6」と読め、真の値は31.12 GiBで、常に同じおよそ4.6パーセント低く出るため、その補正は毎回一定です。

正確な値が必要な場合は、桁区切りを数えてください。キビバイトからメビバイトへは桁区切り三つ分戻って小さな補正、メビバイトからギビバイトへも同様です。二段階の10ビットステップで計算するほうが、一段階の20ビットステップより確認しやすく、途中でメビバイトの数字が目の前に現れるので、コンテナやJVMの設定が求める単位ともちょうど一致します。

通常のメモリページはx86-64で4 KiB、ヒュージページは2 MiBで、カーネルはHugepagesize: 2048 kBと報告します。2,048個のヒュージページとして宣言されたプールは4,194,304 KiB、ちょうど4 GiBです。関係するすべての量が2のべき乗であるため、算術がきれいなまま保たれます。これはヒュージページがそのようなサイズで作られている理由そのものです。

パーセンテージから設定するときはこのきれいさが失われます。62 GiBのマシンの「およそ3分の1」を予約すると10,600ページ、21,708,800 KiB、20.7 GiBになり、この不格好なギビバイトの数字は、それがワークロードからではなくパーセンテージから来た数字であることを示す兆候です。ヒュージページを求めるデータベースや仮想マシンは一般に具体的な数字を求めているので、GiBで指定してから下に換算するほうが扱いやすくなります。

/proc/swapsはSize列を1,024バイトブロックで報告するので、8,388,604ブロックのスワップファイルは8 GiBよりブロック4個分少なく、消えた4キビバイトはスワップ領域が先頭に書き込むヘッダーです。swapon --showは人間可読な形を出力してこの詳細を隠しますが、読むだけなら問題なく、作ったファイルがなぜ4キビバイト足りないのかを解明しようとするときには誤解の元になります。

チューニングノブも同様にキビバイトのままです。vm.min_free_kbytesはアロケータが手を付けない予約量を設定し、デスクトップではよく67,584あたりです。これは66 MiB、0.06 GiBで、ギビバイトの数字は無用になるほど小さく、キビバイトのほうが考えるのに適した単位です。桁の大きさを確認するために換算し、フィールド自体は元のままにしておいてください。