Convert TiB to kB

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 kilobyte is 1,000 bytes when a standards body defines it and 1,024 when an operating system does. This page uses 1,000; the kibibyte is the unit that means 1,024.

Going this way is a multiplication, and by a whole number: one tebibyte is 1,099,511,628 kilobytes, exactly, and 1,099,511,628 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 TiB is 1,024 of the unit below it; one TB is 1,000. On this page that is the difference between 1099511627.776 kB and 1000000000 kB — 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 1000000000 kB where the box said 1099511627.776. 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.

Nine orders of magnitude separate these two units, and the reason to cross them is almost always a count. How many log lines will fit. How many documents. How many days of retention at the current rate. A tebibyte is 1,099,511,627.776 kB, which for every practical purpose is 1.1 billion one-kilobyte records — a figure worth remembering because it turns most of these questions into a single division.

At two kilobytes a record that becomes 549.8 million, at five kilobytes 219.9 million, and at half a kilobyte 2.2 billion. The spread across those three is a factor of ten, driven entirely by the per-record size, while the units question moves the answer by ten per cent. That ordering is the most useful thing to take from this conversion: get the record size right and the prefix will look after itself.

A system writing a thousand lines a second at a kilobyte each produces a megabyte a second, which is 86.4 GB a day. A tebibyte of uncompressed capacity therefore covers 12.7 days. Doubling the line rate halves it, doubling the line size halves it again, and adding a second application writing at the same rate halves it once more. The arithmetic is trivial and the inputs are where the work is.

Retention windows are usually specified before the rate is known, which inverts the calculation: divide the required capacity by the days, and the answer is the daily budget the system has to stay inside. Thirty days at 86.4 GB a day is 2.59 TB, or 2.36 TiB, and that is the figure to compare against the pool before anybody writes a retention policy that the storage cannot honour.

Structured text compresses well because it repeats itself: timestamps in a fixed format, repeated field names, a small vocabulary of message templates. Ratios of five to one and better are ordinary for log data, and the exact figure depends on the content and the algorithm rather than on anything that can be derived from a size. That single factor changes a retention estimate more than every other input combined.

It also has to be applied at the right point. Compression happens on the stored side, so the record count and the ingest rate are in uncompressed kilobytes while the capacity is in compressed ones. Dividing an uncompressed rate into a compressed capacity without the ratio in between gives an answer that is wrong by the whole compression factor, which is an error of hundreds of per cent rather than the ten this page’s units are worth.

A stored record is rarely only its payload. Databases add per-row headers, secondary indexes proportional to the columns they cover, write-ahead logs that hold recent changes twice, and replicas that multiply the whole thing by the replication factor. Search systems store an inverted index that can approach the size of the documents it describes. None of this appears in the kilobyte figure somebody measured on a sample.

The reliable method is to stop estimating the components and measure the system. Load a known number of records into a representative instance, read the occupied size, and divide. The result is a bytes-per-record figure that already includes every overhead the software imposes, and it can be multiplied out to any scale with far more confidence than a sum of guesses about indexes.

Use the exact factor — 1,099,511,627.776 kB to the tebibyte — because it is free and because it stops the ten per cent from creeping in. Then round the answer hard. A retention estimate built on an average record size, an average rate and an assumed compression ratio does not support four significant figures, and reporting one invites somebody downstream to plan against a number that was never that firm.

The honest form of the answer is a range with its assumptions attached: about two weeks uncompressed, about three months at eight to one, assuming a kilobyte a line and a thousand lines a second. Every one of those inputs can be checked and corrected later, which a single figure of 12.7 days cannot.

A terabyte is exactly 1,000,000,000 kB — a clean billion, with no fraction anywhere. A tebibyte is 1,099,511,627.776. That difference in tidiness is a reliable tell when reading somebody else’s spreadsheet: a capacity line showing a round billion kilobytes was derived from a decimal terabyte, whatever the column heading claims, and a line showing 1.0995 billion came from a pool report.

The check is worth running on any sizing document that has passed through more than one person. Mixed conventions in a single sheet are common, because the capacity usually comes from one system and the rate from another, and the resulting ten per cent tends to be attributed to overhead rather than to arithmetic.

Retention arithmetic assumes that expired records stop occupying space, and most storage engines do not work that way. Rows marked for deletion stay on disk until a compaction or cleanup pass runs, log segments are removed whole rather than line by line, and copy-on-write layouts keep old blocks alive for as long as a snapshot references them. The steady state is therefore larger than the retention window implies.

The size of the excess depends on how often the reclamation runs. Where a system compacts daily, the overshoot is roughly one day of ingest, which on 86.4 GB a day is 0.08 TiB and negligible against a large pool. Where it runs weekly, or only when a threshold is crossed, the overshoot can be a substantial fraction of the window and needs to be added to the sizing rather than discovered when the pool fills.

A retention calculation should record five things: the capacity and its unit, the per-record size and how it was obtained, the rate, the compression assumption, and the resulting window. Any of the five can change, and a document that carries all of them can be updated in a minute. One that carries only the conclusion has to be redone from scratch, usually by somebody who will make different assumptions.

Stating the unit explicitly on every capacity figure is the part most often skipped and the part that causes the most trouble. A pool of 20 TiB is 21,990,232,555.52 kB and a pool of 20 TB is 20,000,000,000 — two billion kilobytes apart, which at a kilobyte a record is two billion records of difference in an answer that looked like it was about storage rather than about units.