MiB を KiB に変換

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

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

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

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

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

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

Unix の上限には、値の中で単位を示す方法がまったくないままキビバイトで数えるものが驚くほど多くあります。ulimit -s、ulimit -v、ulimit -m はすべてキビバイトです。/etc/security/limits.conf の stack、data、memlock、as の各列もキビバイトです。rsync の --bwlimit は素の数値を渡すと既定でキビバイト毎秒として扱われます。ディスククォータのブロックもキビバイトです。どの場合もフィールドは整数を保持し、単位は入力できる何かではなくマニュアルページの記述によって決まります。

これが、この換算が読む作業ではなく書く作業になる理由です。8 MiB のスタックや 20 MiB/s の上限が欲しいことは自分でわかっていても、フィールドは 8192 や 20480 を求め、間違えたときのフィードバックはセグメンテーション違反か、意図した速度の千分の一で動く転送か、ほとんど無いに等しいほど大きい上限のどれかです。1,024 を掛けて、その横のコメントにメビバイトの数字を書き残してください。

メビバイトの数字に 1,024 を掛ければ、必ず 1,024 の倍数になり、元が 2 のべき乗のメビバイト数であれば結果も 2 のべき乗になります。設定ファイルを読んで 8192 という値を見つければ、誰かがメビバイトで考えたことがわかり、8000 という値を見つければ誰かがメガバイトで考えていて、意図より 2.4 パーセント小さいフィールドになっていることがわかります。

この食い違いはそれ単体ではめったに問題になりませんが、積み重なると確実に問題になります。8192 の代わりに 8000 に設定された上限は 192 KiB 足りませんが、1 つのプロセスがそれに気づくことはまずありません。フリート全体で 524,288 の代わりに 500,000 に設定されたバッファーはスループットの差として測定可能になり、何も失敗していないため後から原因を特定するのは不可能です。バイナリのフィールドに現れる丸い数字は、いちばん安く手に入る正しさの手がかりです。

ツールが接尾辞を受け付けるなら、それを使うことで算数を省き、同時に意図を記録できます。sort -S 512M、curl --limit-rate 200K、dd bs=4M、rsync --bwlimit=20M はどれも 1 年後に読んでも意味が通りますが、sort -S 524288 はそうなりません。接尾辞は、誰かが値を 2 倍にしようとしたときにも意味を保ちますが、手で掛け算した整数はたいていそうなりません。

例外は、ツール以外の何かがこの値を解析する場合です。監視やコンフィグ管理、監査ツールはこのフィールドを素の整数として比較することが多く、フリート内で 524288 と 512M が混在していると比較が成り立たなくなります。それが当てはまる場合は、整数の形を意図的に選び、ホストごとに著者の好みで記録が変わらないようにしてください。

GNU dd は両方を明記しているのでいちばん分かりやすい例です。bs=1K は 1,024 バイト、bs=1KB は 1,000 バイト、bs=1KiB は前者の同義語として受け付けられます。構文だけではどちらを入力したか手がかりがなく、間違った接尾辞で実行した dd は正しいデータを少しだけ間違ったサイズの単位でコピーし、それはたいてい問題なく動き、宛先が固定のブロックサイズを持つデバイスのときだけ問題を起こします。

それ以外の場所での経験則は、速度を測るものはたいてい 10 進法で、メモリーを測るものはたいてい 2 進法だというものです。ネットワーク工学がキビバイトという単位ができるずっと前から 10 のべき乗を標準にしてきたからです。100 Mbit のリンクは毎秒 100,000,000 ビットであり 104,857,600 ではないため、リンク速度から換算する帯域上限は 10 進法で計算してから、ツールが求めるキビバイトへ変換すべきです。

既定の 8 MiB スタックが 8192 として現れるのは、ulimit -s がその単位で数えているからで、この数字を単にコピーするのではなく換算しておく価値があります。この値はプロセス単位ではなくスレッド単位だからです。何百ものスレッドを使う JVM やスレッド並列型のサーバーは、それだけの回数この量のアドレス空間を確保します。64 ビットマシンではこれは実質無料ですが、32 ビットマシンではメモリーを使い果たすよりずっと前にアドレス空間を使い果たします。

この値を下げることは実際に有効なチューニングであり、実際の危険でもあります。512 KiB——フィールドには 512 と入力します——はたいていのアプリケーションコードには十分ですが、深く再帰するパーサーやスタック上に大きなバッファーを置く処理には足りません。失敗の症状は上限に関するメッセージのないセグメンテーション違反なので、変更のそばにメビバイトの数字を書き残しておく価値があります。0.5 MiB は 512 よりずっと自分の意味を語ってくれます。

PostgreSQL はメモリー単位を kB、MB、GB と表記し、それらを 2 進法で定義しています。そのため shared_buffers、work_mem、maintenance_work_mem、wal_buffers はすべて、10 進法に見えるラベルの下でキビバイト単位の値です。SHOW shared_buffers はそのとき最も扱いやすいと決めた単位で値を返し、pg_settings は 8 KiB ブロック単位で保持しているため、同じ設定値が 128MB、131072 kB、16384 ブロックのどれでも正しく表現されます。

MySQL はオプションの K、M、G 接尾辞付きのバイト数を受け付け、これも同じく 1,024 を基準にしていて、値はバイトで報告されます。両方に共通する実務上の帰結は、チューニングガイドからメガバイト単位でコピーした値は、接頭辞 1 段階につきおよそ 2.4 パーセント、ギガバイト規模の設定に達する頃にはおよそ 7.4 パーセント小さくなっているということです。誰も気づかない程度でありながら、揃えたかったはずの 2 台のサーバーがぴったりとは揃わなくなる程度には大きいずれです。