TB を KiB に変換

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

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

こちら向きの計算は掛け算で、しかも整数です。テラバイト 1 つはちょうど 976,562,500 キビバイト。この 976,562,500 は近い値に落ち着いた測定値ではなく、定義です。

だからこれは、暗算する価値のある数少ない計算のひとつです。検算もできます。割り戻せば、始めた数にきっかり戻るはずです。余地はいっさい残りません。

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 つあるだけです。

何もバイト単位で保存されるわけではありません。ストレージはブロック単位で払い出され、現代のほぼすべてのファイルシステムでブロックは 4 KiB です。それがそのアーキテクチャでのメモリーページのサイズであり、ページと一致するブロックは分割を必要としないからです。ですから 1 テラバイトの有用な読み方は 1,000,000,000,000 バイトではなく 244,140,625 ブロックで、何が収まるかというすべての問いはこの個数に戻ってきます。

この割り算は割り切れます。このカテゴリーでは珍しく、注目に値します。1 兆は十分大きな 2 のべき乗を含むので 1,024 で割り切れ、1 テラバイトはちょうど 976,562,500 KiB、ちょうど 244,140,625 ブロックで余りはありません。二つの体系の間の変換の多くは長い小数で終わりますが、これは算術ができる整数で終わります。

ファイルは丸ごとのブロックを占有するので、すべてのファイルの最後のブロックは部分的に空です。現実的なコレクション全体で平均すると無駄はファイルごとにおよそ半ブロック、およそ 2 KiB です。写真ライブラリでは見えませんが、メールスプールでは膨大になります。100 万ファイルはおよそ 2 GiB を失い、1 億ファイルはおよそ 200 GiB を失い、これは何も間違っていない状態でテラバイトの 5 分の 1 です。

これを危険にしているのは絶対量ではなく比率です。ブロックサイズよりはるかに大きいファイルは数パーセントの端数しか失いませんが、4 KiB 以下のファイルは容量の半分かそれ以上を失うので、1 KB のファイルのディレクトリは 1 TB の内容を 4 TB のブロックに保存することになります。あるコレクションがどれだけ容量を占めるかの見積もりには、合計だけでなくファイルサイズの分布も必要です。

ext ファミリーでは inode の数はファイルシステムの作成時に決まり、あとから変更できません。既定の比率は一定バイト数ごとに 1 個の inode を割り当て、通常の用途には十分ですが、何億もの小さなファイルを保持するボリュームにとってはひどく不足します。inode を使い果たすと、空き容量の表示は健全に見えるのに書き込みが容量不足エラーで失敗し、ファイルシステムが引き起こす中でもとりわけ混乱を招く失敗の一つです。

これはフォーマット時なら避けられますが、あとからでは高くつきます。inode 数を変えることはファイルシステムを作り直すことを意味するからです。ボリュームが非常に多数の小さなオブジェクトを保持する予定なら、既定値のままにするのではなく、予想されるファイル数の見積もりから意図的に個数を選ぶべきです。その見積もりは上と同じブロックの算術を、合計サイズではなく予想されるファイル数に対して行うだけです。

ファイルシステムの下には端末自身の単位があります。ドライブは 512 バイトセクターから 4 KiB の物理セクターへ移行し、多くは互換性のために 4 KiB の物理セクターの上で 512 バイトの論理セクターを提示します。パーティションの開始オフセットが物理セクターの倍数でない場合、すべてのファイルシステムのブロックが二つのセクターにまたがり、各書き込みは両方に対する読み取り・変更・書き込みになります。

その影響は容量の損失ではなく性能の損失で、書き込みでは相当なものになり得ます。現代のパーティション作成ツールは既定で 1 MiB に整列させ、この問題はほぼなくなりましたが、ずっと前に作られてそのまま引き継がれたパーティションテーブルには残っています。ハードウェアが本来出せるはずの性能より悪いボリュームでは確認する価値があります。

大きなオブジェクトストアの容量計画は、実は同時に満たさなければならない二つの予算です。バイト予算は内容が収まるかを問い、オブジェクト予算はブロックとメタデータの個数が収まるかを問います。1 テラバイトは 1 ファイルを保持することも、ブロックの限界で 2 億 4,400 万ファイルを保持することもでき、その両極端の間のすべてがそれぞれ異なるメタデータのコスト、異なるバックアップ時間、異なる復旧時間を持ちます。

忘れられがちなのは二つ目の予算です。ダッシュボードの単一の数字には現れないからです。バイト容量の 40 パーセントしか使っていないボリュームが、実質的に満杯——inode 切れ、あるいはメタデータ処理に時間を取られている——であることがあり、誰もが見る空き容量の数字は、書き込みが失敗するその瞬間まで余裕があると報告し続けます。

この組み合わせは、二つの体系が本当に一つの文の中で共存を強いられる数少ない場所の一つです。容量はメーカーから来て 10 進法です。それがドライブの売られ方だからです。ブロックサイズはカーネルから来て 2 進法です。それがメモリーのページ分けのされ方だからです。どちら側も動かないので、何が収まるかについてのどんな計算も、この二つの間を正確に一度だけ越え、その越え方を意図的に行う必要があります。

これをまっすぐに保つ習慣は、境界でバイトに変換し、そのままとどまることです。容量をバイトで、ブロックサイズをバイトで、ファイルサイズをバイトで、それから割ってください。途中のすべての数字が同じ単位になり、どの段階もどちらの体系にいたか覚えておく必要がなくなります。親しみやすい単位への変換は、算術のあとに行われる表示上の決定であり、算術の最中に行うものではありません。

このページの数字は事前にだけ役に立ちます。それが決める判断のほとんどが、ボリュームを作り直さない限りやり直せないからです。ブロックサイズ、inode 数、整列はすべて作成時に固定されます。10 分でできる見積もり——予想ファイル数、予想サイズ分布、結果として必要なブロックと inode——が、何年も動き続けるボリュームと、予想外の形で満杯になり移行を強いられるボリュームの分かれ目です。

おおまかな見積もりで判断には十分です。予想ファイル数が数百万程度で平均サイズが 4 KiB を大きく上回るなら、既定値で問題なく、考える必要はありません。個数が数億に及ぶ、あるいは平均ファイルサイズがブロックより小さいなら、既定値では足りず、上の算術がどれだけ足りないかを教えてくれます。フォーマットのコマンドと一緒に見積もりを書き留めておく価値があります。次にそのボリュームを見る人が、そのパラメーターが選ばれたものか受け継がれたものかを知りたがるはずだからです。