Convert B to TiB

A byte is eight bits, though that was not always fixed — early machines used six, seven or nine. The eight-bit byte won because it holds one character of text and divides neatly in half.

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.

Going this way is a division, and by a whole number: 1,099,511,627,776 of these fit into one tebibyte with nothing left over. The awkwardness is only that the answers come out as fractions — a third of a tebibyte, a twelfth of one — rather than as the round figures the other direction gives you.

Nothing is lost to rounding even so. The division is exact, and if your answer will not sit still as a decimal — 0.0833… and friends — that is the fraction showing through, not an error creeping in.

One TiB is 1,024 of the unit below it; one TB is 1,000. On this page that is the difference between 1099511627776 B and 1000000000000 B — 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 1000000000000 B where the box said 1099511627776. 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.

Machine interfaces report storage in bytes because bytes need no convention attached. An object-store metric, a du -sb, a quota report or a database size function all return a plain integer, and at this scale that integer is thirteen or fourteen digits long. It is precise, it is unambiguous, and it is unreadable: 4,398,046,511,104 and 439,804,651,104 differ by a factor of ten and look identical at a glance.

That is the actual risk on this conversion, and it is a different risk from the one the smaller data pages carry. Nobody misplaces a factor of ten converting a file size. Everybody is capable of it when reading a fourteen-digit total out of a JSON response, which is why the first useful move is to count the digits rather than to start dividing.

One tebibyte is 1,099,511,627,776 bytes. The useful property of that figure is not its exact value but its shape: it is thirteen digits beginning with a one, so any byte total with thirteen digits is somewhere between about 0.9 and 9 TiB, and a fourteen-digit total is between 9 and 91. A twelve-digit total has not reached a tebibyte at all.

The powers underneath are worth having for the same reason. A gibibyte is 1,073,741,824 — ten digits. A mebibyte is 1,048,576 — seven. A kibibyte is 1,024 — four. Each step up adds three digits and a leading one, which makes the whole ladder checkable by eye and makes a misplaced comma in a spreadsheet obvious the moment the digit count stops matching the label.

The sources cluster into two kinds. Filesystem and block-device tools give exact counts of what exists: du -sb sums apparent sizes, blockdev --getsize64 reports a device capacity, a volume manager reports a pool. Service and billing interfaces give counts of what is stored or transferred: object-store usage metrics, backup catalogue totals, egress meters, quota systems.

The two kinds disagree in ways that have nothing to do with units, and knowing which one produced a figure is more useful than converting it. Allocated size exceeds apparent size on a tree of small files. A backup catalogue counts logical data before deduplication. An object store counts objects and not the space they occupy after erasure coding. Converting the wrong one to TiB gives a precise answer to the wrong question.

At this scale the decimal and binary units have drifted as far apart as they ever do in ordinary use. Dividing by 1,000,000,000,000 gives terabytes; dividing by 1,099,511,627,776 gives tebibytes; the results differ by 9.95 per cent. A dataset of 50,000,000,000,000 bytes is 50 TB and 45.47 TiB, and both figures are correct descriptions of the same thing.

Because the divisors both begin with a one and both have thirteen digits, using the wrong one produces a plausible answer rather than an obviously broken one. The check that catches it is the reverse: multiply the result back by the divisor you think you used and see whether the original integer reappears. It takes a second and it is the only test that distinguishes a unit error from a rounding one.

Every integer up to 9,007,199,254,740,991 — one short of two to the fifty-third, which is exactly 8 PiB — is represented exactly by a double-precision float. That covers every storage figure most systems will ever hold, which is why byte counts pass through JSON, spreadsheets and JavaScript without drifting, and why the convention of reporting bytes over an API is not merely pedantic.

A figure rounded to two decimal places of TiB has thrown away four or five significant digits before anybody sums it. Add a hundred such figures and the accumulated rounding is gigabytes; compare the total against a byte-derived one and they will not reconcile, with no single line responsible. Keep the integers, do the arithmetic on them, and convert once at the end.

Two decimal places of a tebibyte is a precision of about eleven gibibytes, which is finer than most capacity questions are asked at and coarser than any of them need. Three is spurious for a human-facing figure and one is usually enough for a report: 45.5 TiB communicates everything 45.4749 does, and does not invite anyone to treat the last digits as meaningful.

The exception is a figure that will be compared against another figure. Two capacity numbers quoted to one decimal place can differ by a full per cent while appearing identical, so a reconciliation should be done on the byte counts and only its conclusion expressed in tebibytes. Precision belongs where the comparison happens, not where the number is read.

A converted figure should carry its unit explicitly, and at this scale it should usually carry the byte count too. "45.47 TiB (50,000,000,000,000 bytes)" cannot be misread, cannot be re-derived incorrectly, and lets the next reader convert to whatever scale they work in without asking which convention was used.

That is worth more here than on any other pair in this category, because a tera-scale figure is the kind that ends up in a capacity plan, a contract or a board slide, and is quoted back months later by somebody who was not present when it was calculated. The integer is the part that stays true; the unit label is the part that stops it being misapplied.

One pebibyte is 1,125,899,906,842,624 bytes — two to the fiftieth — against a petabyte of 10 to the fifteenth. The divergence has widened again to 12.59 per cent, and a sixteen-digit byte total is where most people meet it for the first time. The pattern holds all the way up: each prefix step multiplies the ratio by 1.024 once more, so exbi against exa is 15.3 per cent and the two scales never converge.

At that size the units stop being a display preference and start being a procurement question, because a tenth of a petabyte is a rack. It is also the point at which the exact byte count becomes the only figure worth exchanging between organisations, since a rounded pebibyte number carries an uncertainty measured in terabytes. The habit of quoting the integer, which is merely tidy at the gibibyte scale, is load-bearing here.