GiB を B に変換

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

1 バイトは 8 ビットですが、いつもそう決まっていたわけではありません。初期の計算機は 6 ビット、7 ビット、9 ビットを使っていました。8 が勝ったのは、そこに 1 文字が収まり、しかもその数がきれいに半分ずつ割れるからです。

こちら向きの計算は掛け算で、しかも整数です。ギビバイト 1 つはちょうど 1,073,741,824 バイト。この 1,073,741,824 は近い値に落ち着いた測定値ではなく、定義です。

だからこれは、暗算する価値のある数少ない計算のひとつです。検算もできます。割り戻せば、始めた数にきっかり戻るはずです。余地はいっさい残りません。

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

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

単位を受け付けず「バイト」とだけ書かれた設定項目は数多くあります。オブジェクトストレージのパートサイズ、アプリケーションフレームワークのリクエストボディ上限、データベース設定のバッファサイズ、API 呼び出しのクォータ。1 ギビバイトの整数は 1,073,741,824 です。両方とも定義された数なので、掛け算に近似は入りません。

丸い十進の数字ではなく二進の単位を選ぶ理由は、その周辺のシステムがすでに二進法だからです。メモリーページ、ブロックサイズ、バッファの割り当て、アドレス範囲はすべて 2 の累乗で、1,000,000,000 バイトの上限はその中で中途半端な位置に来ます。1,073,741,824 なら下層のアロケーターと揃います。

運用ツールの慣習では、接尾辞なしの k、m、g は 1,024、1,048,576、1,073,741,824 を意味します。JVM のヒープフラグは -Xmx4g で 4,294,967,296 バイトを確保します。Docker のメモリーとストレージの上限も同じ、systemd のリソース指定や nginx のサイズ指定も同じです。

GNU coreutils はさらに両方の綴りを受け付け、一文字は二進法、B で終わる二文字は十進法という規則があります。dd bs=1G は 1,073,741,824 バイトのブロック、dd bs=1GB は 1,000,000,000 バイトのブロックで、シェルの履歴ではほとんど見分けがつきません。

Kubernetes のリソース量は構文自体にその区別を持ちます。Gi の接尾辞は二進法で 1Gi は 1,073,741,824 バイト、G だけの接尾辞は十進法で 1G は 1,000,000,000 バイトです。Ki 対 k、Mi 対 M、Ti 対 T も同様に、マニフェストに書かれたとおりの意味になります。

この明快さには鋭い落とし穴もあります。4Gi と書くべきところを 4G と書くと 294,967,296 バイト小さくなり、その差はレビューでは見えません。ワークロードが上限ぎりぎりで動いている場合、この一文字の欠落がポッドが動くか強制終了されるかを分けます。

エラーメッセージや上限欄に繰り返し現れる数字があります。1,048,576 はメビバイト、1,073,741,824 はギビバイト、4,294,967,296 は 2 の 32 乗、つまり 32 ビットアドレス空間ちょうどの大きさです。32 ビットのプロセスがそれ以上確保できない天井でもあります。

それより 1 少ない数字も同じくらい重要です。2,147,483,647 は符号付き 32 ビット整数の最大値で、これで保持されるバイト数はそこで止まります。1.9 GiB でアップロードでき 2.1 GiB で失敗するファイルは、たいてい設定された上限ではなくこの境界に触れています。

コンテナがメモリー上限を超えると識別しやすい状態で強制終了され、ボディサイズの上限を超えたアップロードは明確なステータスコードで拒否されます。どちらも原因の設定を指し示していて、正しいバイト数さえ分かれば直すのは 1 か所の編集です。

静かな失敗のほうが高くつきます。コンテナが許す量より 7 パーセント大きいヒープは起動時には失敗せず、数週間後、負荷がかかったときにようやく失敗します。誤った単位で設定されたキャッシュ上限はエラーすら出さず、想定より頻繁に立ち退きが起きるだけです。

8589934592 という設定行はレビューする人に意図を何も伝えません。書式が式を許すなら 8 1024 1024 * 1024 と書くか、8 ギビバイトだとコメントで示してください。大きなバイト定数はいずれ誰かが検証することになる数字で、導出過程を伴うものだけがリファクタリングを生き延びます。

構文が接尾辞を許すなら、展開した桁より接尾辞を優先してください。1Gi のほとんどの打ち間違いは構文エラーになりますが、i を落とすだけなら 7 パーセントの誤差で済みます。1073741824 の打ち間違いは、桁が 10 倍違う設定として何事もなく動いてしまいます。

この系列は 1,024 の累乗で続きます。テビバイトは 2 の 40 乗、1,099,511,627,776 バイト、ペビバイトは 2 の 50 乗、1,125,899,906,842,624 バイトです。どちらも測定値としてよりは、最大オブジェクトサイズやアドレス空間の天井のような上限として現れます。

実際に効いてくる天井はさらに上にあります。符号なし 64 ビットのバイト数は 16 EiB に達し、現行のシステムはどれもここに近づきません。むしろ数値が浮動小数点として通過する層で精度を失うことのほうが起こり得ます。

何を書いたにせよ、ファイルを信用せず稼働中のシステムから実効値を読み戻してください。コンテナランタイムは適用したメモリー上限を公開していますし、JVM は要求すれば解決済みのヒープ設定を出力します。返ってきた数字をバイトで比較すれば、単位の間違いは一度に見つかります。

これが特に効くのは、2 つの層がそれぞれ違う単位で上限を課している場合です。ギビバイトで書かれたプロセスの上限と、十進のギガバイトで書かれたコンテナの上限の間には、誰も計画していない 7 パーセントの隙間ができ、小さいほうの上限が静かに勝ちます。