TiB を KiB に変換

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

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

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

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

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

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

この二つの単位の間には 30 ビットの差があり、1 テビバイトは 1,073,741,824 キビバイトになり、現実的などんなクォータも一目では読めない数字になります。2 テビバイトは 2147483648、5 は 5368709120、10 は 10737418240。これらがフィールドに入る値で、フィールドはどんな整数でも受け付けます。桁が一つ多いものも含めて。それこそが実際に起きる間違いです。

それを捕まえる習慣は、数字を読むのではなく桁を数えることです。メビバイトはキビバイトで 4 桁、ギビバイトは 7 桁、テビバイトは 10 桁、ペビバイトは 13 桁です。それぞれの単位はほぼ 3 桁ずつ増えるので、1 桁のテビバイトを意図したクォータは 10 桁か 11 桁であるべきで、それ以外は値そのものを見る前から桁が一つずれていることになります。

setquota、edquota、repquota のブロック上限は、下層のファイルシステムのブロックサイズが何であれ、1,024 バイト単位の個数です。この切り離しは意図的です。4 KiB ブロックの ext4 ボリュームに設定されたクォータと、64 KiB ブロックのファイルシステムに設定されたクォータは同じ容量を意味し、ホームディレクトリをその間で移動しても誰の割り当ても静かに変わりません。

これは、報告される数字がファイルシステム自身の会計単位と一致しないことを意味します。4 KiB のブロックを 1,000 個占有するユーザーはクォータブロックとして 4,000 と表示されます。XFS は同じ単位で独自のクォータ実装と別のツールチェーンを持ち、xfs_quota -c 'limit bhard=2t user=alice' は接尾辞を受け付け自分で算術を行います。使える場面ではそちらのほうが良い経路です。

ソフトリミットは牙を持った警告です。超えたユーザーは猶予期間——既定で 7 日——の間は作業を続けられ、猶予が切れるとソフトリミットはハードリミットとして振る舞い始めます。ハードリミットは即座です。書き込みは EDQUOT を返し、アプリケーションはたいていディスク満杯エラーとして報告し、それを見たユーザーは空き容量を確認して十分あることに気づきます。

この二つの差こそ設計判断が宿る場所です。1.8 TiB のソフトリミットと 2 TiB のハードリミットは 214,748,364 キビバイトの猶予と 1 週間の時間を与え、誰かが警告に気づいて容量を空けるには十分です。両方を 2 TiB に設定すれば警告はまったくなく、誰もが最初に知るのは失敗したジョブです。クォータ表の中でこの二つの数字が等しいのは、たいてい設定した人が一つの数字を変換して二回コピーしたからです。

すべてのクォータには、キロバイトではなくファイルを数えるもう一組の上限があり、それは独立しています。2 TiB のブロッククォータに十分収まっているユーザーでも、inode の上限に達していれば書き込みを拒否されることがあり、そのエラーはどちらの天井に達したか示さない同じディスククォータメッセージです。quota -s は両方を示し、ユーザーが「容量はあるはずだ」と主張するときに真っ先に確認すべきものです。

inode の上限が存在するのは、inode がファイルシステム作成時に割り当てられる固定資源で、あとから追加できないからです。何千万もの小さなファイルを作る 1 個のアカウントが、ブロッククォータのごくわずかな割合しか使っていないのに inode を使い果たすことがあり、そうなるとボリューム上の誰もファイルを作れなくなります。ですから inode の上限は、ユーザーを守るのではなくファイルシステムを守るためのもので、何かから変換する必要はありません。

この領域のツールには接尾辞を受け付けるものと受け付けないものがあり、その違いを知ることは変換自体を知ること以上に価値があります。xfs_quota は k、m、g、t を受け付け 2 進法として扱います。最近の setquota のビルドはコマンドラインで同じものを受け付けます。edquota は裸の整数の表をエディターで開き、そこに書かれた値はすべてキビバイトです。ZFS はこの問題自体を回避します。zfs set quota=2T は独自のパーサーを持つデータセットのプロパティです。

裸の整数が避けられない場所では、その隣にテビバイトの数字を記録してください。2147483648 と 2147483648 だけが並ぶクォータ表は正しくても検証できません。同じ表に「ソフト 2 TiB、ハード 2 TiB」とコメントがあれば、ソフトリミットがもっと低くあるべきだったと誰かが気づく機会になります。算術はどちらでも正確で瞬時ですから、賭かっているのは次に読む人が意図を読み取れるかどうかだけです。

クォータが天井なら予約は床で、床のほうがサイズを決めるのが難しいものです。ZFS の予約、保証として使われる XFS のプロジェクトクォータ、保証された最小値を持つシンプロビジョニングのボリュームはどれも、他の誰にも渡されないブロックを取り置きます。2 TiB の予約は、そこに 1 バイトも書き込まれないうちから、プールの利用可能容量の数字から 2,147,483,648 キビバイトを取り除きます。

これが、ほとんど空に見えるプールが満杯だと報告する理由です。データセット全体の予約の合計は、データがほとんど存在しない状態でもプールのサイズに近づくことがあり、空き容量を報告するどのツールも自分の視点からは真実を語っています。予約をキビバイトで計算して合計し、同じ単位でプール全体と比較することがそれを捕まえる確認方法です。テラバイトで行うと丸めが数百ギビバイト分の約束を隠してしまいます。

ブロッククォータはユーザーがどれだけ保存するかを制御しますが、どれだけ書き込むかとは無関係です。大きな一時ファイルを繰り返し作成しては削除する人は、莫大な書き込み増幅を生みながら 2 TiB のクォータの中に無期限にとどまり、フラッシュを消耗し、スナップショットを流動で満たします。懸念がスループットや機器の寿命であって容量でないなら、クォータフィールドはレバーではなく、どんな変換もそれをレバーには変えません。

スナップショットは天井を逆方向に複雑にします。コピーオンライトのファイルシステムでは、スナップショットからまだ参照されている削除済みのデータはどこかにまだ課金されており、クォータの範囲の定め方によっては、削除した本人のユーザーに課金され続けることがあります。テラバイトのファイルを削除したのに使用量が変わらないユーザーは、たいていこれを見ており、修正はブロックフィールドの数字を大きくすることではなく保持ポリシーです。