TB を B に変換

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

1 バイトは 8 ビットですが、いつもそう決まっていたわけではありません。初期の計算機は 6 ビット、7 ビット、9 ビットを使っていました。8 が勝ったのは、そこに 1 文字が収まり、しかもその数がきれいに半分ずつ割れるからです。

テラバイトからバイトへ移ると、小数点が右へ 12 桁ずれます。ほかには何も変わりません。覚えておく倍率もなければ、丸め方を決める必要もありません。数字は同じ並びのまま、位置だけが動きます。

1,234 TB は 1234000000000000 B——同じ数字が、ずれただけです。ひと目で検算できる数少ない計算がこれです。結果の数字が始めたときの数字と違っていたら、それを変えたのはこの計算ではありません。

クォータ、オブジェクトの最大サイズ、ライフサイクルのしきい値、パーティションのオフセット、レート制限、ディスクイメージの宣言。これらはたいてい同じ場所に行き着きます。バイト数だけを受け付ける欄で、それ以外は何もありません。間違えようのある接尾辞も、議論すべき単位もなく、それは見た目より安全ではありません。安全性は接尾辞の中にあり、それを取り除くことでリスクはすべて桁を打つ人に移されます。

これが、なじみのある定数に手を伸ばすのではなく意図的に変換すべき理由です。どこかから貼り付けた値は、その作者が使っていた定義を引き継いでいます。きりの良い数字に丸めた値は、偶然に下された容量についての決定です。テラバイトの要件から出発し、正確な整数を書き出すことで、数字と意図の両方が見える状態を保てます。

1 テラバイトは 1,000,000,000,000 バイトです。これはベンダーによって変わる測定値や慣習ではなく、SI 接頭辞 tera そのものの意味であり、テラヘルツの tera と同じで、ストレージが売買され課金される定義です。2 テラバイトは 2,000,000,000,000、1.5 TB は 1,500,000,000,000 です。この変換は小数点を右へ 12 桁動かすだけで、どこにも丸めはありません。

正確だからこそ、システム間で持ち運ぶ価値があるのはバイトの数字です。同じ容量の他のあらゆる表現——0.909 TiB、931 GB、1000 GB——は、どこかのツールが選んだ表示であり、画面に届くまでに丸められています。バイト数を保存する設定は比較・合計・監査ができますが、「1 TB」を保存する設定は、それを読むものが何かに意味が左右される言葉を保存しているにすぎません。

Kubernetes は両方を受け付け、その数量構文をまねたますます多くのツールも同様です。T は 10 の 12 乗バイト、Ti は 2 の 40 乗、1,099,511,627,776 です。差はおよそ 1 割弱、テラバイトあたりおよそ 100 ギガバイトで、二つの綴りは目で確認するファイルの中で小文字 1 文字しか違いません。

他のツールも警告なく同じように分かれます。GNU coreutils は M と MB、T と TB を区別しているので、dd の bs=1T と bs=1TB は同じコマンドラインの中で異なるブロックサイズになります。コンテナランタイムや JVM のフラグは、裸の g や G を、2 進法の接尾辞を提供せずに 1,024 のべき乗として扱うのが一般的です。すべてに耐えるルールは、欄が許すならバイト数を書き、許さないならそのツール自身の文書を確認することです。

1 TB として売られるドライブは 1,000,000,000,000 バイトを持ち、そのすべてを渡します。1,024 で 3 回割る OS は 931.32 を得てその隣に GB と印字し、この二つの説明の違いはすべて名付け方にあります。これがここで重要なのは、OS が表示した数字から決めたクォータやパーティションは、実際に買った容量から決めたものからおよそ 7 パーセントずれるからです。

実務上の帰結は、作業の方向です。表示ではなく端末そのものからバイト数を取ってください。パーティションツール、ブロックデバイスへの問い合わせ、ドライブ自身が報告するセクター数は整数を返し、その整数こそ設定を組み立てる基盤にすべきものです。端末が手元にないときは、宣伝上の数字をバイトに変換すれば同じ場所にたどり着きます。それがこの正確な 1 兆という数字を暗記しておく価値がある理由です。

区切りのない裸の整数は、ほとんどの設定言語が求める形式であり、人間が確認するには最悪の形式です。失敗はどちらの方向にも静かです。100000000000 は意図した値の 10 分の 1、10000000000000 は 10 倍で、どちらもファイルの中で明らかにおかしくは見えません。1 桁大きすぎるクォータは、何かがそれを満たすまでまったく失敗しません。

二つの確認がほとんどを捕まえます。先頭の桁のあとを 3 桁ずつ数えてください。テラバイトの整数値なら 12 桁あるはずです。形式が許すなら、値を式として書くか区切り記号を使って意図を読めるようにしてください。アンダースコアを受け付ける形式もあり、テラバイトの数字を示すコメントは何のコストもかかりません。どちらもできない場合、数字を手でタイプするのではなく生成することが、この種の誤りをまるごと取り除きます。

二つの体系がいちばん激しく噛みつくのは上限です。上限は、達するまで誰も見返さない数字だからです。5 TB を意図して 2 進法の接尾辞で書かれたストレージクォータは 5.5 TB になり、予算に組まれなかった半テラバイト分の容量が静かに消費されます。保持ポリシーで同じ誤りが起きれば、ポリシー文書が説明するより 1 割多くのデータを保持し続け、これは容量の問題というよりコンプライアンスの問題です。

逆方向に誤りが起きるほうがまだ目立ち、危険は小さくなります。意図より 1 割小さい上限は失敗を生み、失敗は調査されるからです。この非対称性は既存の設定を監査するときに知っておく価値があります。まず確認すべき値は気前の良いほうです。一度も上限に達したことのないクォータは、間違ったクォータと見分けが付かないからです。

この規模のものは現代の算術にとって何も無理をさせません。符号付き 64 ビット整数は 9,223,372,036,854,775,807 に達し、これは 900 万テラバイトを超え、算術と保存の間、特別な扱いなしに値を保持します。JavaScript は整数を 9,007,199,254,740,991——およそ 9 PB——まで正確に保つので、テラバイト規模のバイト数は JSON やブラウザーを無傷で通過しますが、それより上のペタバイトやエクサバイトの数字ではそうはいきません。

いまだに問題を起こす限界は古く狭いものです。符号付き 32 ビットのフィールドは 2,147,483,647 バイトで力尽きるので、そのようにサイズを運ぶツールやプロトコルはテラバイトをまったく表現できず、代わりに起きることはめったにきれいなエラーではありません。この規模のバイト数が消えたりマイナスになったりしたら、それが通過したフィールドがほぼ常に説明であり、このページの変換ではありません。