GiB を TB に変換

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

1 テラバイトは 1 兆バイト、つまり 10¹² です。1 TB として売られるディスクにはきっちりそれだけ入っています。足りなく見えるのは単位の食い違いであって、不足ではありません。

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

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

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

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

この変換の出発点になる数字は、ほぼ必ず機械から出てきたものです。既存のプールのサイズを報告するボリュームマネージャー、データストアを集計するハイパーバイザー、消費傾向を示す監視ダッシュボード。どれも 1,024 のべき乗で計算し、GiB あるいは同じ意味の裸の「GB」を出力します。ゴールは発注書に載る数字で、あらゆる供給業者は 10 進法のテラバイトで見積もります。

ですからこれは算術の練習問題ではなく、境界をまたぐ変換であり、単位が失われがちなのはまさにそういう場所です。要件はエンジニアから調達フォームへ裸の数字として渡り、フォームが 10 進法だからという理由だけで 10 進法として読まれ、頼んだ容量より 7 パーセント少ない容量で発注されます。工程のどこにも間違いはなく、ただ単位が数字と一緒に運ばれなかっただけです。

たいていの単位変換は結果が対称的です。少し多くても少し少なくてもコストはだいたい同じです。これは違います。要件を下回る容量の購入は、設定でもチューニングでもサポートチケットでも直せません。ハードウェアを追加購入することでしか直せず、それは新たな承認、新たな納期、新たなメンテナンスウィンドウを意味します。

ですからルールは、次に手に入る容量まで切り上げ、そのうえで設計上の余裕を足すことです。4,000 GiB は 4.295 TB で、4 TB のドライブより大きなものが必要です。8,000 GiB は 8.59 TB、20,000 GiB は 21.47 TB。どの場合も算術はカタログのサイズをわずかに超えたところに着地します。これは偶然ではありません。カタログのサイズはきりの良い 10 進数で、要件はきりの良い 2 進数だからです。

短い表が調達のほとんどをカバーします。500 GiB は 0.537 TB。1,000 GiB は 1.074 TB。1,024 GiB——1 テビバイト——は 1.0995 TB。2,000 GiB は 2.147 TB。5,000 GiB は 5.369 TB。10,000 GiB は 10.737 TB。GiB から TB への係数は 0.001074、覚えやすく言えば「7.4 パーセント足して小数点を 3 桁動かす」です。

1,024 の行はとくに体に入れておく価値があります。直感が裏切られる場所だからです。1 テビバイトは 1 テラバイトではなく 1.0995 テラバイトなので、2 進法の表示を見ているエンジニアが「1 テラバイト」と表現した要件には 1.1 TB の購入が必要ですが、そんな製品は存在しません。この一つの不一致が、ちょうどわずかに小さすぎることが判明する、数多くのボリュームの背後にあります。

手順の順番が、最後の数字に意味があるかどうかを決めます。要件が測定された単位——GiB——での使用可能容量から始めてください。それが実際に誰かが必要としている数字だからです。それを TB に変換します。そのあとで冗長構成を適用します。これは要件にではなく購入量にかかる乗数です。ミラーなら 2 倍、8 台構成のシングルパリティなら 8 分の 1 増し、8 台構成のダブルパリティなら 4 分の 1 増しです。

逆の順序で行うと、確認できない数字になります。パリティの算術のあとに単位変換をかけると、7.37 パーセントの補正が 25 パーセントの補正に紛れ込み、両方とも見えなくなってしまいます。納品されたアレイが予想より小さいとき、どの段階が間違っていたのか誰にも言えなくなります。それぞれ根拠を持つ二本の別々の行はレビューを乗り切りますが、混ぜ合わせた一つの数字はそうはいきません。

クラウドのコンソールは、この問題がもっとも鋭く現れる場所です。両方の単位がクリック数回の距離に同時に存在するからです。ブロックボリュームがギビバイト単位のサイズで作成され、使用量のグラフがギビバイトで描かれ、料金ページがギガバイト・月あたりの料金を示すのはよくあることです。それぞれは内部的には一貫していますが、組み合わせは直感的ではありません。

実務上の帰結は容量ではなく請求書に現れます。1,000 GiB で作成されたボリュームは 1,074 GB の課金対象ストレージであり、請求額はプロビジョニングの数字から素朴に見積もった額より 7.4 パーセント高くなります。大きな定期的な数字に対する小さな割合であり、まさに四半期遅れで気づかれる種類のコストの振れ幅の形です。

この 7.4 パーセントを余裕代として扱いたくなりますが、変換後の数字を購入してその差を余裕と呼ぶのは間違いです。それは余裕ではなく、正しく書き直された同じ量であり、それを使い切れば設計にはまったく余裕が残りません。成長、スナップショット、ファイルシステムの予約領域、そしてほとんどのストレージが満杯になる前に迎える性能の崖は、それぞれ別枠の余裕であり、それぞれ独自の数字が必要です。

役立つ習慣は、あとから読み返せる連鎖として計画を書くことです。GiB での使用可能要件、同じ数字の TB 表記、構成の乗数、購入サイクルに対する成長の余裕、選んだカタログサイズ。5 行、それぞれが単独で正当化でき、変換は誰でも確認できる形で表に出ています。誰にも確認できない余裕に折り込まれてはいません。

唯一信頼できる防御策は、数字が行くところどこへでも単位を一緒に運ぶことと、組織の境界を越えるときにバイト数を併記することです。「10,737,418,240,000 バイト、つまり 10,000 GiB あるいは 10.74 TB」と書かれた要件は、調達担当者にも供給業者にも、2 年後にこのシステムを引き継ぐ誰にも誤読されません。

これは一行では大げさに見えますが、間違った数字に対して見積もりが返ってきた瞬間、そうは見えなくなります。ストレージは、このサイトの中で単位の食い違いに値段が付く数少ない領域であり、誤りを発見する人がたいてい、それを作った本人ではない領域でもあります。

冗長アレイは、いちばん小さいメンバーが提供する分しか各メンバーから使いません。名目上同じサイズのドライブから組んだセットでも、メーカー間の数ギガバイトの差で容量を失うことがあります。これはドライブがきりの良い 10 進数で売られてきた歴史そのものと同じだけ長く実在する危険で、エンタープライズ向けコントローラーがしばしば構築前にすべてのメンバーを共通の数字に切り下げる理由でもあります。

これがこの変換にとって重要なのは、購入する数字を裸の合計値にしてはいけないということです。40,000 GiB の要件を 42.95 TB に変換し、4 TB のドライブ 11 台で満たすのと、8 TB のドライブ 6 台で満たすのとでは、再構築時間も障害への露出度もパリティ後の使用可能容量もまったく異なります。まず変換し、次にメンバーのサイズを選び、最後に構成を適用してもなお要件を満たしているかを確認してください。