MB を GiB に変換

1 メガバイトは 100 万バイトです。記憶装置のメーカーは昔から十進で数えてきました。だからその数字は、コンピューターが表示する数より大きく見えます。

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

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

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

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

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

ファイルは10進のラベルとともに届きます——700 MBのダウンロード、1,400 MBの動画、合計18,000 MBになるカタログです。コンテナは二進のラベルを持ちます——20 GiBのパーティション、8 GiBのイメージ、ファイルシステムが数える方式のクォータです。片方がもう片方に収まるかどうかは、0.000931322574615478515625を掛ける一回の計算で、これは正確です。

18,000 MBは16.76 GiBなので、20 GiBのボリュームに余裕を持って収まります。うまくいかない習慣は1,000で割って18 GiBと呼んでしまうことで、この方向ではそれは悲観的すぎるだけです——山が実際より大きく見えるだけです。同じ習慣を逆方向、つまり十進のラベルが付いたコンテンツの既知の量に合わせてボリュームをサイズ設定する場面に適用すると、7パーセント不足します。

このペアは一段ではなく二段の体系をまたぐので、数字が見慣れないものになります。一段は1,024対1,000で2.4パーセント、二段では4.9パーセント、MBからGiBが渡る三段では片方向に読むと7.4パーセント、もう片方向では6.9パーセントです。メガバイトからギビバイトの数字は単純な除算の93.1パーセントで、0.931はぱっと見て認識する価値のある定数です。

その対となるのは1.074で、これは逆方向に掛ける数字です。この二つの数字を知っていれば、この規模で起きるストレージの食い違いのほとんどが説明できます。もしある数字がおよそ7パーセントずれていたら、比較対象の一方がはしごの三段を間違った体系でまたいでいるということで、それ以上の調査は必要ありません。

片面1層DVDは両方の数字が見える場所に印刷されているため、いちばん分かりやすい日常の例です。ディスクは4,700,000,000バイトを保持していて、これは標準の定義では4.7 GBで、パッケージにもそう書かれています。Windowsは1,073,741,824で割って4.377を得て、それをGBとラベル付けします。だから同じディスクが箱の上では4.7 GB、画面上では4.37 GBで、その間に何も失われていません。

これが、二進の単位で数えるツールを使って「4.7 GB」を満たすように組み立てたディスクイメージが焼けない理由です。そのツールは自分自身のギガバイトで4.7を満たそうとし、それは50億5,000万バイトに相当しますが、ディスクは47億バイトしか持っていません。これを正しく扱うオーサリングソフトウェアは常にバイトで計算し、間違えたものがこの問題を長年見覚えのあるものにしてきました。

この換算はバイトが収まるかどうかを教えてくれますが、ファイルが収まるかどうかは教えてくれません。それは別の問いだからです。ファイルシステムは自分自身のメタデータ用に容量を確保し、さらに重要なことに、すべてのファイルを整数個のブロック——典型的には4 KiB——で保存するので、100バイトのファイルは4,096バイトを占有し、5,000バイトのファイルは8,192バイトを占有します。ファイルサイズの合計は、それが占有する容量を常に過小評価します。

この過小評価の程度はファイルの構成に完全に依存します。少数の大きなメディアファイルはほとんど何も失いません。各ファイルの最後のブロックだけが部分的に空だからです。何万もの小さなファイルはかなりの割合を失うことがあります——平均1 KBのファイル10万個は100 MBではなくおよそ400 MBを占有します。コンテナを数パーセントの余裕まで満たそうとしているときは、ファイル数が合計と同じくらい重要になります。

仮想化ツールは一般に二進の単位でディスクを作成し、インターフェースはその結果を10進で表示することが多いため、サイズが不格好に見えます。20 GiBとして作成されたディスクは21,474,836,480バイトで21.5 GBと表示され、20 GBとして作成されたディスクは18.6 GiBです。どちらも正当に存在し、両者が同じサイズだと仮定する計画は、大きなホストではドライブ一台分ずれてしまいます。

実務上の進め方は、容量をバイトで決め、ツールが提供するどちらかの単位でディスクを作成し、ラベルではなくバイト数を確認することです。シンプロビジョニングされたディスクにはもう一つ考慮が必要です。論理サイズはゲストが見るもので、物理ファイルはその論理サイズに向かって成長していくため、インターフェース上のどの数字もおかしく見えないまま、ホストが大幅に過剰割り当てされることがあります。

バイトで合計を求め、想定ファイル数分のブロック丸めを加え、ファイルシステムのオーバーヘッドを加え、それから作成ダイアログが求める単位に換算してください。この順序で行うと、それぞれの余裕分が既知の単位の数字に適用され、換算は最後に一度だけ行われチェックできます。他の順序で行うと、ある体系の余裕分と別の体系の合計値が混ざってしまいます。

そのあとは本物の余裕を残してください。技術的に十分な大きさのコンテナは悪い場所です。ファイルシステムは満杯に近づくと遅くなり断片化し、一部は完了するために空き容量そのものを必要とし、内容が少しでも増えればこの作業をすべてやり直すことになります。1〜2割の余裕を確保することは、たいてい安価な費用で将来の作業をまるごと一つ取り除いてくれます。例外は光ディスクのように物理的にサイズが固定されているコンテナで、そこには買い足せる余裕がなく、残された手段は中身をどうするかだけです。

1,000で割ってから7パーセント引いてください。4,700 MBは4.7マイナスおよそ0.33で4.37 GiB、正確な値は4.3772です。18,000 MBは18マイナスおよそ1.26で16.74、正確な値は16.76です。この見積もりはこのペアが使われる範囲全体で1パーセント未満の誤差に収まり、余裕を持って収まるかどうかの判断には十分です。

ぎりぎりの判断には不十分で、まさにそのぎりぎりの場面でこの見積もりが求められがちです。合計がコンテナと数パーセント以内なら、正確な算術を行い、ブロックの丸めも同様に考慮してください。その時点で見積もりと現実の差は残っている余裕とだいたい同じ大きさになります。正確な数字は数秒で済みますが、代わりに1時間動いたコピーの最後で不足に気づくことになります。