Convert TiB to TB

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 terabyte is a trillion bytes. A drive sold as 1 TB is exactly that — the space that seems to go missing is a unit disagreement, not a defect.

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

Every storage project crosses this line twice. The disks are chosen from a price list written in decimal terabytes, the pool that results is reported by software that counts in tebibytes, and the capacity plan somebody wrote in a spreadsheet is usually in whichever unit that person was thinking in. Ten per cent is not a rounding error at this scale; on a sixteen-terabyte purchase it is 1.45 TB, which is more headroom than most plans allow for.

The conversion itself is one multiplication: tebibytes times 1.099511627776 gives terabytes. What makes the page necessary is that the number rarely arrives alone. It comes attached to a parity scheme, a fill recommendation and a file system, each of which removes a further slice, and separating the unit change from the genuine overheads is what turns an alarming figure into a plan.

Start with raw capacity: four disks at 4 TB each is 16 TB, or 16,000,000,000,000 bytes. Divide by 1,099,511,627,776 and the array holds 14.55 TiB, which is the figure a pool report will show before it accounts for redundancy. Nothing has been consumed yet — this is the same 16 trillion bytes expressed in the unit the software prefers.

Single parity takes one disk of capacity, leaving 12 TB usable, which is 10.91 TiB. Double parity leaves 8 TB, or 7.28 TiB. A mirrored pair of pairs gives the same 8 TB by a different route. The number a user finally sees is therefore two subtractions away from the box: a unit change of about ten per cent, then a redundancy cost of a quarter, a half, or whatever the layout charges.

Requirements arrive in tebibytes when they come out of a running system — a backup catalogue, a database size, a pool that is filling. Converting them upward before shopping is the step that prevents an under-order. Twenty tebibytes of data needs 21.99 TB of raw capacity, so a 22 TB purchase covers it exactly and a 20 TB purchase is two terabytes short before a single parity block is written.

Add the overheads in the right order and the shopping list stays honest: convert to decimal first, then divide by the fraction the redundancy layout leaves you, then add the headroom policy. A 20 TiB requirement on single parity across four disks needs 21.99 TB usable, which is 29.3 TB raw, and four 8 TB disks are the smallest set that covers it. Doing the units last is how that calculation quietly comes out at four 6 TB disks instead.

Storage software commonly reports two different totals and they are not the same number. Pool-level commands tend to show raw capacity, including the space that parity will occupy, while file system level commands show what can actually be written. On a raidz set the difference is the parity share, and a reader comparing one tool’s output to another’s can lose a disk’s worth of capacity to a misread label rather than to any real overhead.

The check that resolves it is to convert both figures to decimal terabytes and compare them against the disks physically installed. The raw figure should land within a per cent or so of the sum of the box capacities; the usable figure should be the raw one minus the redundancy cost. If neither matches, the discrepancy is a configuration question rather than a units question, and it is worth finding before the array is filled.

The discrepancy compounds, one factor of 1.024 per prefix. A kibibyte sits 2.4 per cent above a kilobyte, a mebibyte 4.9 per cent above a megabyte, a gibibyte 7.4 per cent above a gigabyte, and a tebibyte 9.95 per cent above a terabyte. Nothing about the tera step is special except that it is the fourth one, and the errors have been multiplying since the first.

That is why capacity planning goes wrong at array scale and almost never at file scale. Mixing the units on a document costs a few bytes nobody notices. Mixing them on a sixteen-terabyte pool costs 1.45 TB, which is more than most people budget for headroom, and the mistake shows up months later as a pool filling faster than the growth curve predicted.

Copy-on-write file systems slow markedly as they approach full, and the usual guidance is to keep utilisation below eighty per cent on a pool that sees regular writes. That reservation comes off after every other reduction, so the 10.91 TiB usable from four 4 TB disks on single parity is a practical 8.73 TiB, which is 9.6 TB. The distance between the invoice and the working figure is by then substantial and none of it is a fault.

Stating the chain explicitly in the capacity plan is what stops the argument recurring: raw decimal, raw binary, usable after parity, working after headroom. Four numbers, each derived from the last, each labelled with the unit it is in. A plan that carries only the first and the last invites somebody to conclude that seven terabytes went missing.

Striped and parity layouts work in equal-sized units, so a set built from disks of unequal capacity generally uses the smallest disk’s size for every member. Adding a 12 TB disk to a set of 4 TB disks contributes 4 TB and leaves the remaining 8 unused, and no amount of converting units will reveal that from the pool total — it appears as a capacity that grew by less than the invoice suggested.

Expansion strategies differ in how they handle this, and some can use the excess by treating the array as several groups. The figure to work out before buying is what the layout will actually claim from each disk, in decimal terabytes, and then convert the sum once. Converting first and reasoning about the layout afterwards produces a binary number that describes a configuration nobody is going to build.

Nominally identical disks from different manufacturers do not always present the same byte count, and a replacement that is a few megabytes smaller than the disk it replaces can be refused by an array that expects at least the original size. The industry works to an agreed byte count per capacity class for exactly this reason, but drives outside that convention exist and the failure is discovered at the worst moment.

The defence is to record the byte count rather than the label when the array is built. A disk described as 4 TB might present 4,000,787,030,016 bytes; the number to keep is that one, in bytes, alongside the 3.638 TiB the pool reports for it. Both figures are unambiguous, and a replacement can be checked against them before the old disk is pulled.