TiB を TB に変換

1 テビバイトは 1,024 ギビバイトです。テラバイトとの隔たりは階段を上がるごとに開いていきます。キロで 2.4 %、メガで 4.9 %、ギガで 7.4 %、テラで 10 %。

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

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

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

どんなストレージのプロジェクトもこの境界を2回越えます。ディスクは10進法のテラバイトで書かれた価格表から選ばれ、そこからできるプールはテビバイトで数えるソフトによって報告され、誰かがスプレッドシートに書いた容量計画は、その人がそのとき考えていたどちらかの単位です。10パーセントはこの規模では丸め誤差ではありません。16テラバイトの購入では1.45TBになり、これはたいていの計画が見込んでいる余裕より大きい量です。

変換自体は1回の掛け算です。テビバイトに1.099511627776を掛ければテラバイトになります。このページが必要になるのは、その数字がめったに単独では出てこないからです。冗長化の方式やフィル推奨、ファイルシステムがそれぞれさらに一部を取り除いていき、単位の変化とほんとうのオーバーヘッドを切り分けることが、驚くほどの数字を計画に変える鍵です。

まず生の容量から始めます。4TBのディスク4台は16TB、16,000,000,000,000バイトです。1,099,511,627,776で割るとアレイは14.55TiBを保持し、これは冗長化を考慮する前にプールのレポートが示す数字です。まだ何も消費されていません。これは16兆バイトを、そのソフトが好む単位で表しただけです。

シングルパリティなら1台分の容量が消え、12TBの実利用容量、10.91TiBになります。ダブルパリティなら8TB、7.28TiBです。2組のミラーペアも別の経路で同じ8TBになります。ユーザーが最終的に目にする数字は、箱から2回の引き算を経ています。まず約10パーセントの単位変換、それから冗長化のレイアウトが課す4分の1、半分、あるいはそのレイアウトが課すものです。

要件は、稼働中のシステム——バックアップのカタログ、データベースのサイズ、埋まりつつあるプール——から出てきたときはテビバイトで届きます。買い物の前にそれを上方向に変換しておくことが、発注不足を防ぐ段階です。20テビバイトのデータには21.99TBの生の容量が必要なので、22TBの購入で過不足なく足り、20TBの購入ではパリティブロックを1つ書く前から2テラバイト足りません。

オーバーヘッドを正しい順序で足していけば買い物リストは正直なままです。まず10進法に変換し、次に冗長化のレイアウトが残す割合で割り、それから余裕の方針を足してください。4台構成のシングルパリティで20TiBの要件は21.99TBの実利用容量が必要で、これは29.3TBの生の容量になり、4台の8TBディスクがそれをカバーする最小構成です。単位の変換を最後に回すと、静かに4台の6TBディスクという答えにたどり着いてしまいます。

ストレージソフトはしばしば2つの合計を報告し、それらは同じ数字ではありません。プールレベルのコマンドはパリティが占める容量を含めた生の容量を示す傾向があり、ファイルシステムレベルのコマンドは実際に書き込める容量を示します。raidzのセットではその差がパリティの取り分です。あるツールの出力を別のツールと比べる人は、本物のオーバーヘッドではなく読み違えたラベルのせいで、ディスク1台分の容量を見失うことがあります。

それを解消するチェックは、両方の数字を10進法のテラバイトに変換し、実際に搭載されているディスクの合計と比べることです。生の数字は搭載されたディスク容量の合計のおよそ1パーセント以内に収まるはずで、実利用の数字は生の数字から冗長化のコストを引いたものになるはずです。どちらも一致しなければ、それは単位の問題ではなく設定の問題であり、プールを埋める前に見つけておく価値があります。

この差は接頭辞1段につき1.024倍で積み重なります。キビバイトはキロバイトより2.4パーセント上、メビバイトはメガバイトより4.9パーセント上、ギビバイトはギガバイトより7.4パーセント上、テビバイトはテラバイトより9.95パーセント上です。テラの段が特別なわけではなく、これが4番目の段だというだけで、誤差は最初の段からずっと掛け合わされ続けています。

だから容量計画はアレイの規模では狂いやすく、ファイルの規模ではほとんど狂いません。1つの文書で単位を混ぜても誰も気づかないほどのバイト数しかかかりません。16テラバイトのプールで混ぜると1.45TBかかり、これはたいていの人が見込む余裕より大きく、この間違いは何か月も経ってから、プールが成長曲線の予測より速く埋まっていくという形で表面化します。

コピーオンライトのファイルシステムは満杯に近づくと目に見えて遅くなり、一般的な指針は、日常的に書き込みが行われるプールでは使用率を80パーセント未満に保つことです。この予約はほかのすべての控除のあとに来るので、4台の4TBディスクをシングルパリティで組んだときの実利用10.91TiBは、実質的な作業容量として8.73TiB、9.6TBになります。請求書の数字と実際に使える数字のあいだの距離は、そこまで来るとかなり大きくなり、そのどれも不具合ではありません。

この連鎖を容量計画の中に明示しておくことが、同じ議論が繰り返されるのを防ぎます。生の10進法、生の2進法、パリティ後の実利用、余裕を差し引いたあとの作業容量。この4つの数字を、それぞれ元になった数字とともに、それぞれの単位を明記して書いてください。最初と最後だけを持つ計画は、誰かに「7テラバイトはどこへ消えたのか」と結論づけさせてしまいます。

ストライプやパリティのレイアウトは同じ大きさの単位で動くので、大きさの違うディスクで構成されたセットは一般に、いちばん小さいディスクのサイズをメンバー全員に使います。4TBのディスクのセットに12TBのディスクを足すと、それは4TBぶんだけ貢献し、残りの8TBは使われないままで、プールの合計をいくら単位変換しても、それがどこに消えたかは見えてきません。表示上のプール容量は請求書が示唆したより小さく増えたように見えるだけです。

拡張の戦略はこれをどう扱うかで違います。アレイをいくつかのグループとして扱うことで超過分を利用できるものもあります。買う前に確認すべき数字は、そのレイアウトが実際に各ディスクからいくら取るかを10進法のテラバイトで計算し、それから合計を一度だけ変換することです。先に変換してからレイアウトを考えると、誰も組む予定のない構成を表す2進法の数字ができあがってしまいます。

公称は同じ容量でも、メーカーの違うディスクが常に同じバイト数を示すとは限らず、置き換え用ディスクが元のディスクよりわずかに小さいと、元のディスク以上のサイズを求めるアレイに拒否されることがあります。業界はまさにこのために容量クラスごとの合意されたバイト数を目安にしていますが、その慣行の外にあるドライブも存在し、その不具合はいちばんまずい瞬間に見つかります。

対策はラベルではなくバイト数を記録しておくことです。「4TB」と表示されたディスクは実際には4,000,787,030,016バイトを示すことがあり、記録しておくべきなのはその数字で、そのディスクについてプールが報告する3.638TiBと一緒に控えておきます。どちらの数字も曖昧さがなく、古いディスクを抜く前に置き換え用ディスクをそれと照合できます。