Convert KiB to TiB

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 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,073,741,824 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 KiB is 1,024 of the unit below it; one kB is 1,000. On this page that is the difference between 0 TiB and 0 TiB — 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 TiB 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.

Kibibyte to tebibyte is three ten-bit steps stacked, 2³⁰ in total, and it is the only conversion on this site where a four-digit input becomes a number with a decimal point ten places deep. A modest 500,000 KiB is 0.000466 TiB. A meaningful tebibyte figure needs an input with at least nine digits in it, which is a useful filter: if the kibibyte number in front of you is short, this is the wrong conversion and mebibytes is the unit you want.

The exponent is also why the two units are almost never printed by the same tool. Kibibytes are what a per-file or per-page accounting uses, because 1,024 bytes is close to the granularity a filesystem actually works in. Tebibytes are what a whole-array figure uses. A tool that reported both would be showing a quantity and its billionth part in the same table.

df -k on a large volume produces columns like 15,623,913,472 and no separators, and the eye is very bad at eleven undelimited digits. The reliable habit is to count them: ten digits is a few tebibytes, eleven is tens, twelve is hundreds. Formally, divide by 1,073,741,824; practically, strike nine digits and take seven per cent off what remains.

That approximation is worth naming because a plain billion sits between the two divisors it could stand for: 1.0737 billion kibibytes make a tebibyte and 0.977 billion make a terabyte. So striking nine digits and stopping there leaves you seven per cent high against tebibytes and two and a half per cent low against decimal terabytes. 15,623,913,472 KiB is 14.55 TiB, and calling it 15.6 of anything is the error the shortcut invites.

An unsigned 32-bit counter of kibibytes reaches 4,294,967,296 KiB and stops, which is exactly 4 TiB. A 32-bit counter of 512-byte sectors reaches 2 TiB. A 32-bit counter of 4 KiB blocks reaches 16 TiB, which is where ext3 stops. None of these numbers was chosen by anybody; each is 2³² multiplied by whatever unit the format happened to count in, and knowing that lets you work backwards from a ceiling to the field that caused it.

The practical value of the conversion here is checking a planned size against one of them before the array is built rather than after. A pool that will grow to 3.8 TiB is 4,080,218,931 KiB and is comfortably inside a 32-bit kibibyte count; one that will reach 4.2 TiB is not, and the failure when it arrives is rarely a clear error message.

With the usual 4 KiB block, one tebibyte is 2²⁸ blocks — 268,435,456 of them — and that count, not the byte figure, is what governs the expensive operations. A full fsck walks the block and inode tables, so its runtime and its memory appetite scale with the block count; so does the time to create the filesystem, and so does the metadata a snapshot has to track.

It is also the number that decides the inode ratio. mkfs.ext4 allocates one inode per 16 KiB by default, so a 4 TiB filesystem is created with around 268 million inodes whether or not it will ever hold that many files. Each costs 256 bytes of disk, which is about 64 GiB of the array spent before a single file exists — visible as the gap between the raw size and what df reports as available on a brand-new volume.

Adding up a few thousand per-filesystem kibibyte figures to get an estate total is the commonest reason anybody performs this conversion, and it is where the arithmetic quietly goes wrong. A 32-bit signed integer stops at 2,147,483,647, which is 2 TiB expressed in kibibytes, and shell arithmetic in older environments and a good many monitoring agents used exactly that width. The symptom is a total that goes negative or wraps to something small when one more volume is added.

Anything using double-precision floats — awk, most scripting languages, spreadsheets — is safe here for a different reason: integers stay exact up to 2⁵³, which in kibibytes is eight exbibytes. Convert at the end rather than per row, keep the running total in kibibytes, and the only rounding in the whole exercise is the one you choose when you print the tebibyte figure.

Ten per cent separates the terabyte from the tebibyte, and at array scale that is a quantity somebody paid for. A shelf of twelve 8 TB drives is 96 TB on the invoice and 87.31 TiB before any redundancy, and the 8.7 TiB difference is not overhead, shortfall or a fault — it is the same bytes counted in a different base. Every figure in this conversion is on the binary side of that line.

The confusion is worth heading off in writing rather than in a meeting. A capacity plan that mixes a vendor figure in TB with a df figure in TiB will be out by a tenth in the direction that looks like missing hardware, and the argument that follows is expensive. Stating the array in kibibytes once, converting once, and labelling the result TiB removes it.

A kibibyte block count is an allocation figure, and at tebibyte scale the difference between allocation and content can run to whole terabytes. Sparse files report far fewer blocks than their length; a compressed filesystem such as ZFS with compression on, or Btrfs, reports blocks after compression, so the kibibyte total is smaller than the data it holds. Deduplication makes the same figure smaller again and no longer additive across volumes.

Where the number is going into a backup estimate or a migration plan, the useful quantity is the logical size and the kibibyte block count will understate it, sometimes badly. df and zfs list answer different questions on the same pool for exactly this reason, and converting either to tebibytes cannot reconcile them — that has to happen before the conversion, not after it.