Convert MiB to TiB

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 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,048,576 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 MiB is 1,024 of the unit below it; one MB is 1,000. On this page that is the difference between 0 TiB and 0 TiB — 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 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.

The gap between the two units is 2²⁰, so any figure that is meaningfully expressed in tebibytes and was collected in mebibytes was assembled from something on the order of a million items — objects in a bucket, daily volumes over years, files in a media library, chunks in a backup catalogue. That is the useful frame for the conversion: the division itself is exact and trivial, and everything that can be wrong about the answer was already wrong before the division happened.

It also sets the precision that is worth carrying. Three significant figures in tebibytes corresponds to about a thousand mebibytes, so a total quoted as 14.6 TiB has already discarded a gibibyte of detail and there is no point arguing about the last few objects. Where the total is a budget rather than a measurement, two significant figures is usually all the input deserves.

The commonest shape of this calculation is a rate times a period. A log pipeline ingesting 4,200 MiB a day holds 1,533,000 MiB after a year, which is 1.46 TiB; the same pipeline with a ninety-day retention holds 378,000 MiB, or 0.36 TiB, and the difference between those two figures is usually the whole content of a retention policy discussion.

Two adjustments are worth making before the number is quoted. Growth compounds, so a volume rising ten per cent a quarter is 46 per cent higher after a year and the naive product understates the peak rather than the average. And retention is enforced by deletion, which lags — a ninety-day policy on a system that sweeps weekly holds up to ninety-seven days. Both push the same direction, and a plan sized on the flat product is a plan sized slightly short.

Object storage inventories usually offer a count and a total, from which an average falls out, and the average is the least useful statistic the distribution has. Real buckets are long-tailed: a median object of tens of kibibytes with a mean in the megabytes means a handful of large objects carry most of the bytes, and any estimate that multiplies the count by the mean will be roughly right about capacity and useless about everything else.

The things it gets wrong are the ones that cost time rather than space. Restore duration, listing cost, request charges and transfer parallelism all scale with the object count, not the byte total, and a tebibyte spread across four hundred objects behaves nothing like a tebibyte spread across forty million. Where the tebibyte figure is going into a recovery plan, carry the count alongside it rather than the average.

A stored object is more than its payload. Object stores keep metadata per object; filesystems keep an inode and directory entry per file; several storage tiers bill a minimum object size regardless of the true one, which turns a bucket of small objects into a bill several times the sum of their lengths. Ceph writes RADOS objects at a default 4 MiB and a smaller payload does not fill one.

None of this shows up in a mebibyte column exported from an inventory, so the conversion produces an accurate total of payload bytes and an understatement of what the storage will cost. The correction is a multiplier applied to the object count rather than to the byte total, which is why the count has to survive the aggregation. Ten million objects with a 128 KiB billable floor is 1.19 TiB of billing before the payload is considered at all.

Integer arithmetic is safe here further than instinct suggests. Double-precision floats represent every integer exactly up to 2⁵³, which in mebibytes is more than eight billion tebibytes, so a spreadsheet, an awk script or a JavaScript reduce over an inventory will not lose a byte as long as the values it adds are whole numbers. The width of the accumulator is not the risk.

The risk is converting early. Turning each row into a fractional tebibyte figure and summing those does round at every step, because a value like 0.0000038 TiB has no exact binary representation and a million of them accumulate a visible error. Sum in the smallest unit the data offers — bytes if you have them, mebibytes if you do not — and convert exactly once, at the end, when a person is going to read the result.

A mebibyte sum is logical size, and almost no storage system stores logical size. Three-way replication triples it. Erasure coding adds a fraction determined by the scheme — a 6+3 layout costs 1.5 times the payload, an 8+2 layout 1.25. RAID 6 across ten drives costs 1.25. Snapshots add whatever has diverged since they were taken, which is unbounded and rarely modelled.

Compression pulls the other way and is applied before replication rather than after, so the order matters: logical total, then compression ratio, then replication or coding overhead, then any per-object floor. Doing those in a different order gives a different answer, and a capacity plan that does not state the order it used cannot be checked by anybody else. Write the raw tebibyte figure down first and derive the rest from it in sequence.

Below about a tenth of a tebibyte the unit stops helping. 104,858 MiB is 0.1 TiB, and a reader handles "102 GiB" far better than a number with a leading zero and three decimal places. The threshold worth applying is whether the figure has two digits before the decimal point; if it does not, drop a step and use gibibytes.

Above the tebibyte, the same logic applies again at 1,024 of them, and there is a second reason to be careful: pebibyte-scale figures are usually quoted against contracts and invoices, which are written in decimal. A plan that reaches four digits of tebibytes is a plan that will be read next to a number in terabytes, and the ten per cent between them is worth stating explicitly rather than leaving for somebody to discover.