KiB を TB に変換

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

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

こちら向きの計算は割り算で、しかも整数で割り切れます。976,562,500 単位が余りなく テラバイト 1 つに収まります。不便なのは、結果が分数で出てくることだけです——3 分の 1、12 分の 1——逆向きなら得られる、きりのよい整数の代わりに。

それでも丸めで失われるものはありません。割り算が割り切れるからです。結果が小数で収まらない場合——0.0833… のような——それは分数が顔を出しているのであって、誤差が入り込んでいるのではありません。

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

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

ディスク使用量やクォータのツールはブロック単位で報告します。それがファイルシステム自体の数え方だからで、ストレージの規模になると結果はどんな接頭辞の手がかりもない数字の羅列になります。1キビバイトのブロック32億個の合計は3,276,800,000,000バイト、3.28TBです。同じ数字をブロックが1,000バイトであるかのように読むと3.2TBになり、静かに77GBが消えます。

変換は2つの手順で、どちらの順でも構いません。1,024を掛けてバイトに、10の12乗で割ってテラバイトに。あるいはブロック数に1.024を掛けて小数点を9桁動かすかです。後者のほうが手計算しやすく、補正の大きさもはっきり見えます。答えは常に単純な読み方より2.4パーセント上で、下になることはありません。

1テラバイトは976,562,500キビバイト、1テビバイトは1,073,741,824キビバイトです。一方は9で始まる9桁の数字、もう一方は1で始まる10桁の数字で、ブロック数がどちらかに近いということは、おおよそテラバイト級の何かを表していますが、どちらの単位かによって答えは1.00になるか1.10になるか変わります。

見分け方はその数字が何から作られたかです。実際に蓄積されたものを積み上げて出た数字であれば、それは測定値で、たどり着く場所にたどり着きます。ボリュームサイズやクォータの上限、機器の総容量のような容量から来た数字であれば、ほぼ確実に10進法の数字から派生していて、1,024で割られて途中を経ていて、変換し直すと不自然に丸い数字に戻ります。

危険な思い込みは、ブロックがキビバイトだというものです。k フラグを付けてツールを呼び出したときはたいていそうですが、ファイルの保存ブロック数は古くからの慣習で512バイト単位で表され、一部の集計ツールはファイルシステム自体のブロックサイズ——よく4,096バイト——を使います。読み違えると2倍か8倍の誤差になり、容量計画における8倍の誤差は些細なものではありません。

安価な確認方法は、既知の量を同じツールに通してみることです。バイト数がわかっているファイルを同じツールで測り、返ってきたブロック数を見ればブロックサイズが1回でわかります。ツールごとに1回これを行い、出力を解析するスクリプトの隣に答えを書いておけば、この種の誤りをすべて防げます。

ディレクトリの走査は見つけられるものを積み上げます。マウントポイントの下に潜らなかったファイル、稼働中のプロセスがまだ開いている削除済みファイル、ファイルシステムが自分のために確保している空間はどれも見えず、何にも計上されません。ボリュームレベルのレポートはそれらすべてを含みます。この2つの数字は違う問いへの答えであり、その差が数パーセントあることは普通です。

ハードリンクはもう1つのずれの原因です。1回の走査の中ではリンクされたファイルは1回だけ数えられ、これは正しい振る舞いですが、複数のディレクトリごとの合計を足し合わせると、合計ごとに1回ずつ数えられます。変わらないファイルをバックアップ間でハードリンクによって共有するスナップショットの構造は、まさにこの仕組みの上に成り立っているので、素朴な合計は実際に占めている容量の何倍にもなり得ます。

まず変換し、そのあとにコストを別々に順番に足してください。10進法テラバイトの数字、意図するレイアウトの冗長性係数、ファイルシステムのオーバーヘッド、機器の寿命にわたる想定される増加、そして予備の余白の方針です。40億ブロックの合計は4.096TBです。4台構成のパリティ1台なら4分の3で割るので5.46TBの生の容量が必要になり、そこから増加分と余白の方針が引かれます。

この5つの数字を分けたまま持つことが、1年後に計画を見直しやすくします。1つの合成係数はすっきりして見えますが、アレイが予定より早く埋まったときにどの前提が間違っていたかを隠してしまいます。単位の変換はこの5つの中で唯一正確なもので、残りの推定と混ぜ合わせるべきではありません。

ブロック数はファイルシステムが割り当てたものを測っていて、普通のボリュームではそれがデータの必要量の良い目安になります。透過的に圧縮するボリュームや、ファイルをまたいで同じブロックを重複排除するボリュームでは、この関係が崩れます。同じデータがそちらではより少ないブロック数に収まり、これから買おうとしているドライブでは同じようには収まらないので、ブロック数の合計はもう必要量を予測できません。

誤差の方向は、測定した側のシステムによって決まります。普通の置き場所から圧縮する行き先をサイジングすると発注が不足し、よく圧縮されるデータでは大きな倍率になることがあります。逆に圧縮する行き先を普通の置き場所からサイジングすると発注が過剰になり、こちらのほうが安上がりな間違いです。どちらにせよ変換すべき数字は、計画しているものと同じ機能を持つボリュームで測定されたものであるべきで、それが手元にない場合は比率を仮定として明示するしかありません。