TiB を GiB に変換

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

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

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

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

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

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

ストレージを要求するインターフェースのほとんどはギビバイトの数字を受け取ります。クラウドのブロックボリュームは整数のGiBで割り当てられます。Kubernetesの永続ボリューム要求は storage: 100Gi と書きます。VMのディスクや LVM の論理ボリューム、iSCSI のターゲットも同じ規模で指定されます。その背後にあるプール——アレイやSAN、ZFSのプール——はテラバイトで語られます。それが購入という行為が起きる単位だからです。

だからこの変換は実質、件数への割り算です。10TiBのプールは10,240GiBで、これは100GiBのボリューム102個、あるいは512GiBの20個、あるいは2,048GiBの5個です。最初のボリュームを作る前にその件数を出しておくことが、プールの寿命を予測可能にし、これはリクエストが来るたびに1件ずつ割り当てていくと省略されがちな段階です。

シンプロビジョニングされたボリュームは自分の全容量をゲストに報告しますが、消費するのは書き込まれたブロックだけです。だから100GiBのボリューム100個——10,000GiBの約束——が2TiBのプールに乗って、消費量は800GiBに収まることがあり得ます。これは仕掛けではなく本物の効率化です。ほとんどのボリュームはほとんど空であり、決して存在しないデータのために容量を予約しておくのは無駄だからです。

露出しているのは、その約束が本物であるのにプールがそうではないことです。合計使用量がプールのサイズに近づくと、書き込みは失敗し始めます。それぞれのボリューム自身の空き容量の表示は「まだたっぷり残っている」と言っているにもかかわらずです。ゲストのファイルシステムにはそれを解釈する術がなく、正常なデバイスだとカーネルが信じているものへの書き込み失敗は、きれいなエラーというよりファイルシステムの破損として現れがちです。だからシンプールは個々のボリュームではなくプール自身の使用量を監視する必要があり、ディスクを買い足す時間を稼げるだけの余裕を持ったしきい値でアラートを設定する必要があります。

LVM のシンプールは、割り当てられた各チャンクをその場所へ対応づけるメタデータボリュームを持っていて、プールの作成時にサイズが決まります。それはデータ量ではなくチャンク数と、そのチャンクを共有するスナップショットの数に応じて大きくなるので、100個のスナップショットにまたがる控えめな数百ギビバイトのプールでも、データ領域はほぼ空のままメタデータが尽きることがあります。

この失敗は容量が尽きるより悪いものです。メタデータが尽きたシンプールは書き込みを受け付けなくなり、一般に読み取り専用になり、たいてい thin_check と thin_repair でオフラインでの修復が必要になります。lvs -o+metadata_percent がその数字を報告し、データ領域より低いしきい値で独自のアラートに値します。データ不足と違い、ファイルを削除するだけでは直せないからです。

ギビバイトの数字を分ける前に、プールから3つを差し引いておくべきです。スナップショットの余地は、データサイズではなく書き換え率次第です。満杯になる前に劣化し始めるためのフィルセーリング。そしてリビルドや移行、復元——プールがもっとも満杯なときにいちばん必要になりやすい操作——を完了できるだけの空き容量です。

10TiBのプールで、20パーセントをフィルセーリングに、さらに1TiBをスナップショットと操作の余地に取っておくと、割り当てられる容量は約7,168GiBになり、これは100GiBのボリューム102個ではなく71個です。この差は最初に決めておく必要があります。すでに配布したボリュームから容量を取り戻すにはボリュームを縮小することになり、縮小はうまく機能しない操作だからです。

クラウドのブロックストレージは整数のギビバイトで割り当てられ、使用量にかかわらず提供されたギビバイト月数で課金されます。100GiBのリクエストは1ギビバイトしか書き込まれなくても99ギビバイトが書き込まれても100として課金され、単位がGiBのAPIに対して100GBというつもりでリクエストすると、10進法の数字が示唆するより7.4パーセント多い容量と7.4パーセント多いコストが返ってきます。見積もりと請求がおよそ15分の1ずれているとき、たいていこれが原因です。

この丸めは、小さいボリュームが積み重なると不釣り合いに高くつく形でも表れます。8GiBのボリュームが500個あれば4,000GiB、3.9TiBの提供容量になり、平均利用率が4分の1なら請求のうち約3テビバイトが空の容量です。少数のより大きいボリュームを共有ファイルシステムでまとめることが通常の答えで、それを正当化する算術はまさにこの変換を、割り当てられた数字ではなく実際に使われた数字で行ったものです。

ボリュームを拡張してからその上のファイルシステムを拡張することは、ext4やXFSをはじめとするほとんどの現行の構成ではオンラインで行える操作で、数秒で終わります。逆方向はまったく別の問題です。ファイルシステムはデバイスを切り詰める前にデバイスの末尾からすべてを移動させなければならず、XFSはそれをまったくできず、ext4はファイルシステムをアンマウントする必要があります。実用上、ボリュームサイズは片方向の決定です。

この非対称性が最初の割り当ての決め方を左右すべきです。ボリュームを小さく始めて必要に応じて拡張していくのは、拡張ごとに数分の手間をかけますが、プールの空き容量を必要とする誰にでも使える状態に保ちます。最初から誰かがいつか必要になるかもしれないと推測したサイズで始めるのは、二度と回収できない割り当てにプールを固定してしまいます。シンプールではこの主張は弱くなります。未使用のブロックは消費されないからですが、それでもメタデータの問題と、2TiBの空きがあると報告するボリュームが人に与える心理的な効果は残ります。

2のべき乗、あるいは少なくともテビバイトのきれいな分数になるサイズを選べば、残りの容量を考えやすくなります。10,240GiBは128、256、512、1,024、2,048GiBのボリュームにきれいに割り切れて、末尾に半端なものを残しません。標準サイズを750GiBにすると、13個のボリュームのあとに490GiBが取り残されます。14個目には足りず、無視するには多すぎる量です。

同じことが下にある割り当て単位にも当てはまります。LVMのエクステント、シンプールのチャンクサイズ、RAIDのストライプはどれも粒度を持っていて、ギビバイトの整数倍のサイズはそのどれの整数倍にもなります。これはいちばん安上がりな整然さです。どちらの方向でも算術は正確であり、きれいに割り切れるほうが2年後にも誰かが検証できる版だからです。