GB を MiB に変換

1 ギガバイトは 10 億バイトです。ディスクのメーカー、通信のデータ容量、動画のサイズが使っているのと同じ十進の意味です。

1 メビバイトは 1,024 キビバイト、つまり 1,048,576 バイトです。Linux のツールとメモリーの数値は、表示が「MB」であってもほぼ常にこちらを指しています。

倍率は 953.674316 で、これをそのまま持ち歩く人はまずいません。950 に丸めると 0.39 % ずれます。小さい数では見えもしませんが、1,000 GB あたりで、ずれは丸ごと 1 単位になります。

丸める前に知っておく価値があるのは、ずれの大きさそのものではなく、それを無視できなくなる地点のほうです。それより下なら短い倍率が賢明で、それより上なら上の入力欄を使ってください。あちらは書き出す前に丸めません。

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

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

1 ギガバイトは 10 億バイトです。1 メビバイトは 1,048,576 バイトです。片方をもう片方で割ると 953.67431640625 という、丸めなしで正確に出る数字になります。誰も直感では出せない数字で、たいてい調べることになります。反射的に 1,000 か 1,024 に手を伸ばしがちですが、この換算は 2 つの体系をまたぐため、どちらも間違っています。

誤差の大きさはどちらの数字を選ぶかで変わります。1,000 を使うと 4.9 パーセント過大になり、1,024 を使うと 7.4 パーセント過大になります。ダッシュボードならわずかにずれた線で済みますが、しきい値なら選んでいないパーセンテージで警報が鳴ることになり、容量計画なら予測が余裕を持たせたつもりの瞬間に 7 パーセント不足することになります。

しきい値はたいてい、何かに対する割合として意図されています。ディスクの 80 パーセントで警告する、メモリー上限の 90 パーセントでページするなど。この意図が保たれるのは、割り当てそのものの単位で割合を取り、最後に一度だけ換算した場合だけです。1 ギガバイトの 80 パーセントは 762.9 MiB で、90 パーセントは 858.3 MiB です。どちらも自分から入力したくなる数字ではありません。

その代わりに人が入力してしまうのは 800 や 900 という、丸くても意図した割合ではない数字です。800 MiB は 1 ギガバイトの 84 パーセント、900 MiB は 94 パーセントに相当します。警告自体は動きますが、ランブックが説明している割合より遅れて発火し、そのずれはルールと文書のどちらにも一見もっともらしい丸い数字が入っているために気づかれません。

Prometheus はこの問題についてどちらの立場も取りません。エクスポーター側の慣習は、_bytes という接尾辞を付けた生のバイト数を記録し、表示層に単位の選択を委ねることです。これは正しい設計で、選択をダッシュボードに移すことになりますが、その選択はフィールドごとに、たいていパネルを作った人によって行われ、グラフを見る人が目にする場所に記録されることはほとんどありません。

実際に起きるのは、同じダッシュボード上の 2 つのパネルが同じ系列を 7 パーセントずれて表示していても、両方とも正しく設定されているという状況です。クエリはバイト数を返し、片方のパネルは SI の意味で整形し、もう片方は IEC の意味で整形します。軸には GB と GiB、あるいはもっと悪いことにどちらも GB と表示されます。ダッシュボード上の数字を他の何かと比較する必要があるときは、軸のラベルよりまずそのフィールドの単位設定を確認してください。

コンテナのリソース設定は、この換算がいちばんよく行われ、いちばん見過ごされる場所です。Kubernetes は両方の体系を受け付け、正しく区別しています。Mi と Gi は 2 進法の数量、M と G は 10 進法の数量です。1G という上限は 1,000,000,000 バイトで、1Gi は 1,073,741,824 バイトです。どちらも有効な指定で、どちらも警告なしに適用され、両者は 7.4 パーセントずれています。

罠になるのは、鎖の各段で単位が変わっていく場合です。容量は 10 進法の GB で購入され、ノードは GiB で表記され、上限は Mi で書かれ、ダッシュボードは設定された単位で表示されます。この鎖の各段はそれぞれ問題なく変換できますが、失敗するのはその 3 つを目で暗算しようとすることです。数字が比較される場所で一度だけすべてをバイトに換算し、扱いやすい単位は表示専用にとどめてください。

実用的な目安はあり、目安として扱うべきです。プランや割り当て、請求額、転送許容量のような「購入したもの」を説明する数字はほぼ常に 10 進法です。それが容量が販売される単位だからです。使用中のメモリーやページキャッシュ、Linux のファイルシステム空き容量のような「稼働中のマシンの内部から来る」数字はほぼ常に 2 進法です。それがカーネルが数えている単位だからです。

この目安が通用しない場面には、通用する検証方法があります。バイト単位で独立して測定できる量を見つけ、それをそのコンソールに通してみて、どちらの割り算が表示された数字を再現するかを確認してください。1 回の観測で済み、そのコンソールについてはそれで恒久的に決着し、その結論に至らないかもしれない文書を読み続けるより有意義な 5 分になります。

何も見えません。それが厄介な点です。本来より 5 パーセント高い位置にある線は、正しい線とまったく同じ形、同じ傾向、同じ変化率を持ち、疑いを招くものは何もありません。この誤りが見えるようになるのは、そのグラフを請求額や割り当て、別のツールといった外部の数字と比べたときだけで、そのときには単位の問題ではなく謎として現れます。

見た目で気づける唯一の手がかりは、ちょうど合わない余裕線です。使用量の系列が、別の場所から取った容量の線に対して 100 パーセントではなく 93 パーセントや 107 パーセントで頭打ちになっているなら、その比率は測定の誤差ではなく単位のずれです。1.074 と 0.931 が覚えておく価値のある 2 つの数字で、1.049 と 0.954 はその 1 段階小さい版です。