Convert MiB to TB

A mebibyte is 1,024 kibibytes, or 1,048,576 bytes. Linux tools and memory sizes generally mean this even when they print "MB".

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.

The factor is 0.000001, and almost nobody carries that around. Rounded to 0.000001 it is off by 0.14 % — which stays invisible on small numbers and turns into a whole unit somewhere around 1,000 MiB.

That is the number worth knowing before you round: not the error itself, but where it stops being ignorable. Below that point the shorter factor is the sensible one; above it, use the field above, which never rounds until it prints.

One MiB is 1,024 of the unit below it; one MB is 1,000. On this page that is the difference between 0 TB and 0 TB — 4.9 % — 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 4.9 %. A drive sold in MB 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.

Agents report in mebibytes because that is what the machine counts in, and invoices are in decimal terabytes because that is how capacity is sold. Between the two sits an addition that looks trivial and is where a fleet report goes wrong: one million MiB is 1,048,576,000,000 bytes, which is 1.049 TB, not 1. Multiply that error across a real estate and the report and the bill part company by nearly 5 percent.

The discrepancy behaves badly because it scales exactly with the total. It is never a fixed offset that somebody can spot and subtract; it is always the same percentage, so it looks like a systematic overcharge rather than a unit error. That is why this particular mistake gets escalated to the provider more often than it gets found in the aggregation.

Reconciliation is only possible in a unit both sides agree on, and neither TB nor MiB is that unit until somebody says which they mean. Bytes is. Take the monitoring total and expand it to bytes, take the billed quantity and expand it to bytes, and compare those two numbers; if they now match to within the measurement window, there was never a billing problem and the whole difference was the label.

When they still do not match, the residual is worth reading rather than dismissing. Storage bills usually count things a usage dashboard does not: snapshots, replicas, incomplete multipart uploads, deleted objects still inside a retention window. Those produce a difference with a shape — it appears at particular times, it is not a fixed percentage — which is exactly how you tell it apart from a unit error that is 4.9 percent of everything, always.

Add in bytes and convert once, at the end. Converting each host's figure to terabytes and summing the results introduces a rounding error per host, and with a large enough fleet those errors are a visible quantity even when each one is negligible. A single multiplication applied to an exact integer total cannot drift; several thousand small divisions applied before the sum can.

The same rule covers the intermediate storage. A byte total for a fleet is a large integer, and it should stay an integer through the aggregation rather than becoming a float that averages, rounds and formats along the way. Where it must be transported through a document format with no exact integer type at that magnitude, carry it as a string and parse it back at the point of comparison.

A pipeline has three points where the convention can flip, and each looks innocuous. The exporter chooses what it emits, and the well-behaved ones emit raw bytes with a _bytes suffix. The aggregation chooses whether to divide, and often does so with a constant typed by hand. The presentation layer chooses a format, and its choice is stored in a dashboard definition nobody reads.

The one to audit first is the middle one, because it is the only place a wrong constant becomes permanent. A recording rule that divides by 1,000,000 to make megabytes and is then displayed as MiB has baked a 4.9 percent error into stored data, and every report built on it afterwards inherits it. Displays can be corrected retroactively; a stored aggregate cannot. The audit is short: find every constant in the recording rules, check each against the unit its output is labelled with, and record the answer next to the rule so nobody has to repeat the exercise the next time a figure looks wrong.

A growth forecast multiplies whatever error is in its base figure. Six months at 10 percent monthly growth turns a 4.9 percent understatement into a 4.9 percent understatement of a number nearly twice as large, which in absolute terms is the difference between ordering the right amount of capacity and ordering visibly too little. The percentage does not grow; the quantity it applies to does.

The defence is to forecast in bytes and convert only when presenting, exactly as with the aggregation. It also helps to state the assumption in the forecast itself: a line saying the figures are decimal terabytes derived from byte counts takes one sentence, and it is the sentence that lets somebody six months later check the number instead of rebuilding it.

TB alone is ambiguous in practice, whatever the standard says, because a substantial share of software prints TB and means tebibytes. TiB is not ambiguous, and a figure written with an i in it has told the reader everything they need. Where the audience will not recognise TiB, the fallback that works is the decimal figure with the byte count beside it, which nobody can misread and everybody can check.

For a recurring report the labelling belongs in the template rather than in each edition, so it cannot be dropped by whoever produces the next one under time pressure. A footer stating the unit and its definition costs one line and removes the most common reason a capacity number is quietly re-derived by its reader, which is the outcome the report existed to prevent. The same line is what lets an auditor or a finance team check the figure independently, which is usually the reason the report is produced in the first place.

A million mebibytes is a little over a terabyte — five percent over — so the mental version is to take the MiB total, move the decimal point six places, and add a twentieth. Four and a half million MiB is 4.5 plus about 0.22, which is 4.72 TB against 4.7186 exactly. That is close enough to catch a factor-of-ten error and a missed conversion, which are the two errors that matter.

The corresponding check in the other direction is that a decimal terabyte is about 954 thousand mebibytes. Any figure claiming a terabyte from a million MiB, or a million MiB from a terabyte, has treated the two systems as interchangeable, and the five percent it dropped is the same five percent that will not reconcile against the invoice later. Both checks take longer to describe than to perform, and either one would have caught every unit error this page is about before it reached a report somebody else had to defend.