Convert KiB to TB

A kibibyte is exactly 1,024 bytes. The name was coined in 1998 precisely so that "kilobyte" could go back to meaning 1,000, though the habit never fully took.

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.

Going this way is a division, and by a whole number: 976,562,500 of these fit into one terabyte with nothing left over. The awkwardness is only that the answers come out as fractions — a third of a terabyte, 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 KiB is 1,024 of the unit below it; one kB is 1,000. On this page that is the difference between 0 TB and 0 TB — 2.4 % — 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 2.4 %. A drive sold in kB holds exactly what the label says; Windows divides by 1,024 instead of 1,000, keeps the decimal name, and reports 0 TB where the box said 0. 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.

Disk usage and quota tools report in blocks because that is what the file system counts in, and at storage scale the result is a string of digits with no prefix to anchor it. A total of 3,200,000,000 blocks of a kibibyte each is 3,276,800,000,000 bytes, or 3.28 TB. Reading the same figure as though the blocks were thousands of bytes gives 3.2 TB and quietly loses 77 GB.

The conversion is two steps that can be done in either order: multiply by 1,024 for bytes, divide by a trillion for terabytes, or multiply the block count by 1.024 and shift the decimal point nine places. The second form is easier by hand and makes the size of the correction obvious — the answer is always 2.4 per cent above the naive reading, never below it.

A terabyte is 976,562,500 kibibytes and a tebibyte is 1,073,741,824. One is a nine-digit number starting with a nine and the other a ten-digit number starting with a one, and a block total sitting near either is describing roughly a terabyte of something — but which one it is decides whether the answer is 1.00 or 1.10 in the units a drive is sold in.

The way to tell is by what produced the number. If the total came from adding up what is stored, it is a measurement and will land wherever it lands. If it came from a capacity — a volume size, a quota ceiling, a device total — it was almost certainly derived from a decimal figure and divided by 1,024 on the way, and it will convert back to something suspiciously round.

The dangerous assumption is that a block is a kibibyte. It usually is when a tool was invoked with a k flag, but a file’s stored block count is expressed in 512-byte units by long-standing convention, and some reporting tools use the file system’s configured block size, which is commonly 4,096 bytes. Guessing wrong is a factor of two or eight, and a factor of eight in a capacity plan is not a subtle error.

The cheap check is to convert a known quantity. Take a file whose byte length you know, run it through the same tool, and see what block count comes back; the ratio tells you the block size in one step. Doing that once per tool, and writing the answer next to the script that parses the output, prevents the entire class of mistake permanently.

A directory walk adds up what it can see. Files under a mount point it did not descend into are missing, files that have been deleted but are still held open by a running process are missing, and space the file system has reserved for itself is not attributed to anything. A volume-level report includes all of it. The two numbers are answers to different questions and a difference of a few per cent between them is normal.

Hard links add a second kind of divergence. Within one traversal a linked file is counted once, which is the right behaviour, but summing several per-directory totals counts it once per total. Snapshot layouts that use hard links to share unchanged files between backups are built precisely on this, so a naive sum across snapshot directories can report several times the storage that is actually occupied.

Convert first, then add the costs separately and in order: the decimal terabyte figure, the redundancy factor for the layout you intend, the file system overhead, the growth expected over the life of the hardware, and the headroom policy. A total of 4,000,000,000 blocks is 4.096 TB; single parity across four disks means dividing by three quarters, so 5.46 TB of raw capacity, and a growth allowance and headroom policy come off that.

Keeping the five figures separate is what makes the plan reviewable a year later. A single combined multiplier looks tidy and hides which assumption was wrong when the array fills early. The units conversion is the only one of the five that is exact, and it should not be blended into the four that are estimates.

The gap between a kibibyte and a kilobyte is the smallest in this family of units, and it is the one most often ignored — which is defensible on a file and not on a volume. At four terabytes the same 2.4 per cent is 96 GB, which is more than the file system overhead the plan probably did account for, and it is systematically in the direction that makes the estimate too small.

It also compounds with the mistake it is most often made alongside. A reader who treats a kibibyte as a thousand bytes and then compares the result against a drive whose capacity they assumed was binary has made two errors of different sizes in the same direction, and the combined shortfall runs close to ten per cent. Doing the units carefully once removes both.

A block total measures what the file system has allocated, which on a plain volume is a good proxy for what the data needs. On a volume that compresses transparently, or one that deduplicates identical blocks across files, the relationship breaks: the same data occupies fewer blocks here than it will on the drive you are about to buy, and the block total no longer predicts the requirement.

The direction of the error depends on which system was measured. Sizing a plain destination from a compressed source under-orders, sometimes by a large factor on data that compresses well. Sizing a compressing destination from a plain source over-orders, which is the cheaper mistake. Either way, the number to convert is the one measured on a volume with the same features as the one being planned, and where that is not available the ratio has to be stated as an assumption rather than folded into the total.

Before a block total becomes a purchase order, check it against the volume the data currently sits on. The used figure from a volume-level report, converted the same way, should be in the same neighbourhood as the walk total; if it is not, one of the two is measuring something you did not intend and it is worth finding out which before the number is committed to.

The other check is against physical reality. Convert the answer back to the number of disks it implies at current capacities and see whether it is plausible. A calculation that concludes a modest file server holds forty terabytes has usually double-counted a snapshot tree, and noticing that at the arithmetic stage is considerably cheaper than noticing it after the drives arrive.