Convert TB to KiB

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.

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.

Going this way is a multiplication, and by a whole number: one terabyte is 976,562,500 kibibytes, exactly, and 976,562,500 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 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.

Nothing stores a file byte by byte. Storage is handed out in blocks, and on almost every modern filesystem a block is 4 KiB, because that is the memory page size on the architectures it runs on and a block that matches a page needs no splitting. So the useful reading of a terabyte is not 1,000,000,000,000 bytes but 244,140,625 blocks, and every question about what fits comes back to that count.

The division is exact, which is unusual for this category and worth noticing: a trillion is divisible by 1,024 because it contains a power of two large enough, so a terabyte is exactly 976,562,500 KiB and exactly 244,140,625 blocks with no remainder. Most conversions between the two systems end in a long decimal; this one ends in a whole number you can do arithmetic with.

A file occupies whole blocks, so the last block of every file is partly empty. Averaged over a realistic collection the waste is about half a block each, which is roughly 2 KiB per file. That is invisible on a photo library and enormous on a mail spool: a million files lose about 2 GiB and a hundred million lose about 200 GiB, which is a fifth of the terabyte before anything has gone wrong.

The ratio is what makes it dangerous rather than the absolute figure. Files far above the block size lose a fraction of a percent; files at or below 4 KiB lose half their space or more, so a directory of 1 KB files stores 1 TB of content in 4 TB of blocks. Any estimate of how much a collection will occupy has to know the file-size distribution as well as the total.

On the ext family the number of inodes is decided when the filesystem is created and cannot be changed afterwards. The default ratio allocates one inode per fixed number of bytes, which is generous for ordinary use and badly wrong for a volume that will hold hundreds of millions of small files. When they run out, writes fail with a no-space error while the free-space figure looks healthy, which is one of the more confusing failures a filesystem produces.

It is avoidable at format time and expensive afterwards, since changing the inode count means rebuilding the filesystem. If a volume is going to hold a very large number of small objects, the count should be chosen deliberately from an estimate of the file count rather than left at the default — and the estimate is the same block arithmetic as above, run against the expected number of files rather than their total size.

Below the filesystem the device has its own unit. Drives moved from 512-byte sectors to 4 KiB physical sectors, and many present 512-byte logical sectors over 4 KiB physical ones for compatibility. When a partition starts at an offset that is not a multiple of the physical sector, every filesystem block straddles two of them, and each write becomes a read-modify-write of both.

The effect is a performance loss rather than a capacity loss, and it can be substantial on writes. Modern partitioning tools align to 1 MiB by default and the problem has largely gone away, but it survives in partition tables created long ago and copied forward, and it is worth checking on any volume that performs worse than its hardware should allow.

Capacity planning for a large object store is really two budgets that have to be satisfied at once. The byte budget asks whether the content fits; the object budget asks whether the block and metadata counts fit. A terabyte can hold one file or, at the block limit, 244 million of them, and everything between those extremes has a different metadata cost, a different backup time and a different recovery time.

The second budget is the one that gets forgotten, because it does not appear in any single number on a dashboard. A volume at 40 percent of its byte capacity can be effectively full — out of inodes, or spending all its time in metadata — and the free-space figure that everybody watches will report it as comfortable right up to the point that a write fails.

This pair is one of the places the two systems are genuinely forced to share a sentence. The capacity comes from a manufacturer and is decimal because that is how drives are sold; the block size comes from a kernel and is binary because that is how memory is paged. Neither side is going to move, so any calculation about how much fits crosses between them exactly once and has to do it deliberately.

The habit that keeps it straight is to convert to bytes at the boundary and stay there. Capacity in bytes, block size in bytes, file sizes in bytes, then divide — every intermediate figure is in the same unit and no step has to remember which system it was in. Converting to a friendly unit is a display decision made after the arithmetic, never during it.

The numbers on this page are only useful in advance, because most of the decisions they inform cannot be revisited without rebuilding the volume. Block size, inode count and alignment are all set at creation. An estimate that takes ten minutes — expected file count, expected size distribution, resulting block and inode demand — is the difference between a volume that works for years and one that has to be migrated when it fills in an unexpected way.

A rough version is enough to make the decision. If the expected file count is in the low millions and average sizes are well above 4 KiB, the defaults are fine and nothing needs thinking about. If the count runs into the hundreds of millions, or the average file is smaller than a block, the defaults will not do and the arithmetic above is what tells you by how much. Writing the estimate down alongside the format command is worth the extra minute, because the next person to look at the volume will want to know whether its parameters were chosen or inherited.