Convert TiB to GiB

A tebibyte is 1,024 gibibytes. The gap against the terabyte has grown with each step: 2.4% at kilo, 4.9% at mega, 7.4% at giga, 10% at tera.

A gibibyte is 1,073,741,824 bytes — about 7% more than a gigabyte. Windows measures in gibibytes and labels them GB, which is the whole of the missing-space mystery.

Going this way is a multiplication, and by a whole number: one tebibyte is 1,024 gibibytes, exactly, and 1,024 is the definition rather than a measurement that came close.

That makes it one of the few conversions worth doing in your head, and it makes the answer checkable: divide back and you must land on the number you started with, exactly, with no remainder to explain away.

One TiB is 1,024 of the unit below it; one TB is 1,000. On this page that is the difference between 1024 GiB and 931.3226 GiB — 10 % — and the gap grows at every step up the scale, which is why it is a rounding error on a photograph and a visible chunk of a hard disk.

This is the whole of the missing-storage mystery, and on this page it is worth 10 %. A drive sold in TB holds exactly what the label says; Windows divides by 1,024 instead of 1,000, keeps the decimal name, and reports 931.3226 GiB where the box said 1024. macOS has counted these in the decimal units since 10.6, which is why the same drive can look two sizes on two machines — nothing is missing and nobody is rounding, the same bytes have two names.

Almost every interface that requests storage takes a gibibyte figure. Cloud block volumes are provisioned in whole GiB. A Kubernetes persistent volume claim is written storage: 100Gi. VM disks, LVM logical volumes and iSCSI targets are all specified at that scale. The pool behind them — an array, a SAN, a ZFS pool — is described in tebibytes, because that is the unit a purchase happens in.

So the conversion is really a division into a count. A 10 TiB pool is 10,240 GiB, which is 102 volumes of 100 GiB, or 20 of 512, or 5 of 2,048. Working out that count before the first volume is created is what makes the pool's lifetime predictable, and it is the step that gets skipped when volumes are provisioned one at a time in response to requests.

A thin-provisioned volume reports its full size to the guest and consumes only the blocks that have been written. That is why a hundred 100 GiB volumes — 10,000 GiB of promises — can sit on a 2 TiB pool while consuming 800 GiB, and it is a genuine efficiency rather than a trick: most volumes are mostly empty, and reserving space for data that will never exist is waste.

The exposure is that the promises are real and the pool is not. When aggregate usage approaches the pool size, writes start failing on volumes whose own free-space figure says there is plenty, and the guest filesystems have no way to interpret that — a write failure on what the kernel believes is a healthy device tends to produce filesystem corruption rather than a clean error. Thin pools therefore need monitoring on the pool's usage rather than on any volume's, and an alert threshold with enough headroom to buy disks.

An LVM thin pool keeps a metadata volume mapping every allocated chunk to its location, and it is sized when the pool is created. It grows with the number of chunks and with the number of snapshots sharing them, not with the amount of data, so a pool holding a modest few hundred gibibytes across a hundred snapshots can exhaust its metadata while the data area is nearly empty.

The failure is worse than running out of space. A thin pool whose metadata fills stops accepting writes and generally has to be repaired offline with thin_check and thin_repair before it will come back. lvs -o+metadata_percent reports the figure and it deserves an alert of its own at a lower threshold than the data area, because unlike data exhaustion it cannot be fixed by deleting files.

Three deductions come off the pool before the gibibyte figure is divided. Snapshot space, which depends on rewrite rate rather than on data size. A fill ceiling, because most pools degrade well before full. And enough free space to complete a rebuild, a migration or a restore — the operation that is most likely to be needed at exactly the moment the pool is most full.

On a 10 TiB pool, holding twenty per cent for the ceiling and a further tebibyte for snapshots and manoeuvre leaves about 7,168 GiB to allocate, which is 71 volumes of 100 GiB rather than 102. That difference is large enough that it has to be decided up front, because reclaiming space from volumes already handed out means shrinking them, and shrinking is the operation that does not work.

Cloud block storage is provisioned in whole gibibytes and billed per provisioned gibibyte-month regardless of use. A request for 100 GiB is billed at 100 whether one gibibyte or ninety-nine are written, and a request phrased as 100 GB against an API whose unit is GiB gets 7.4 per cent more capacity and 7.4 per cent more cost than the decimal figure suggested. Where a quote and an invoice differ by roughly a fifteenth, this is usually why.

The same rounding makes small volumes disproportionately expensive in aggregate. Five hundred volumes of 8 GiB is 4,000 GiB provisioned, or 3.9 TiB, and if the average utilisation is a quarter then three tebibytes of the bill is empty space. Consolidating onto fewer, larger volumes with a shared filesystem is the usual answer, and the arithmetic that justifies it is exactly this conversion run over the provisioned rather than the used figures.

Extending a volume and then extending the filesystem on it is an online operation on ext4, XFS and most modern stacks, and it takes seconds. Going the other way is a different class of problem: the filesystem must relocate everything away from the end of the device before the device can be truncated, XFS cannot do it at all, and ext4 requires the filesystem unmounted. In practice a volume size is a one-way decision.

That asymmetry should shape the initial allocation. Starting volumes small and growing them on demand costs a few minutes of work per growth and keeps the pool's free space available to whoever needs it most; starting them at the size somebody guessed they might eventually need locks the pool up in allocations that will never be reclaimed. On a thin pool the argument is weaker, because unused blocks are not consumed — but the metadata and the psychological effect of a volume reporting 2 TiB free both still apply.

Choosing sizes that are powers of two, or at least clean fractions of a tebibyte, makes the remaining capacity easy to reason about. 10,240 GiB divides exactly into volumes of 128, 256, 512, 1,024 or 2,048 GiB and leaves nothing awkward at the end. A standard size of 750 GiB leaves 490 GiB stranded after thirteen volumes — not enough for a fourteenth and too much to ignore.

The same applies to the underlying allocation unit. LVM extents, thin-pool chunk sizes and RAID stripes all have granularities that a volume size either matches or does not, and a size that is a whole number of gibibytes is a whole number of every one of them. It is the cheapest kind of tidiness: the arithmetic is exact either way, and the version that divides cleanly is the one somebody can still audit in two years.