Convert MB to TiB

A megabyte is a million bytes. Storage manufacturers have always used this decimal meaning, which is why their capacities look larger than what a computer reports.

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.

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

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 TiB is 1,024 of the unit below it; one TB is 1,000. On this page that is the difference between 1099511.6278 MB and 1000000 MB — 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 1000000 MB where the box said 1099511.6278. 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.

Individual files are naturally described in megabytes — a photograph, a track, a scan, a nightly dump — and the storage that holds them is reported by pool software in tebibytes. Between those two numbers lie six prefix steps and the decimal-to-binary line, and the aggregate is where both start to matter. A tebibyte holds 1,099,511.63 MB, so the useful approximation is 1.1 million megabytes to the tebibyte.

That figure makes most of these estimates arithmetic anybody can do standing up. A library of 400,000 files averaging 4 MB is 1,600,000 MB, which is 1.46 TiB. Two years of nightly dumps at 800 MB each is 584,000 MB, or 0.53 TiB. The precision that matters here is in the average file size, which is usually a guess, rather than in the conversion, which is exact.

At 5 MB a file, a tebibyte holds about 219,900 of them. At 30 MB — a RAW frame from a full-frame camera — it holds 36,650. At 800 MB, the size of a compressed database dump of moderate size, it holds 1,374. Those three numbers span two orders of magnitude and all describe the same capacity, which is why a capacity plan that does not state the assumed file size is not a plan.

Recording rates behave the same way. Video written at 45 GB an hour fills a tebibyte in a little over twenty-four hours of footage. A camera producing 1,200 frames a day at 30 MB fills it in about a month. Neither figure is affected by the unit question by more than ten per cent, and both are affected by the settings on the device by a factor of several.

Every file is rounded up to a whole allocation block, so a library of small files occupies more than its contents. At a 4 KiB block size the average waste is about 2 KiB per file, which on 400,000 files is 800 MB — a rounding error against a tebibyte, and not against a pool that is nearly full. Directories, metadata and the file system’s own structures add further.

Media libraries add their own overhead on top. Sidecar files carrying edits, generated previews at several sizes, and a catalogue database that grows with the collection can add a substantial percentage to the raw file total, and none of it appears in the figure a camera reports per frame. Measuring the occupied size of a representative folder and comparing it against the sum of the file lengths gives a multiplier that can be applied to the whole estimate.

A static total answers the wrong question. What determines a purchase is the rate: megabytes per week, per shoot, per backup cycle. Convert the rate into the same units as the remaining capacity and divide, and the answer is a date rather than a percentage. Remaining capacity of 3 TiB against a growth of 60,000 MB a week is 3,298,535 MB divided by 60,000, which is 55 weeks.

Rates are also where a units mistake compounds instead of sitting still. A weekly figure that is ten per cent low because a tebibyte was read as a terabyte produces a forecast that is ten per cent optimistic every week, and the error accumulates in the same direction as the growth it is trying to predict. The pool fills earlier than the plan said, and the plan looks approximately right until the week it does not.

The discrepancy between the decimal and binary prefixes compounds at every step: 2.4 per cent at kilo, 4.9 at mega, 7.4 at giga and 9.95 at tera. At the megabyte end of this conversion the difference is genuinely negligible, which is why nobody worries about it on a single file. At the tebibyte end it is a hundred gigabytes on a single pool.

That asymmetry is what makes this particular conversion worth doing carefully rather than approximately. The reader’s instinct, formed at file scale where the units barely differ, is that a factor of a million is close enough. It is not: 1,000,000 MB is 0.909 TiB, and a tebibyte holds 1,099,512 MB rather than a round million. Treating the two as interchangeable misstates a pool by about a hundred gigabytes, and which direction the error runs in depends on which end of the conversion somebody rounded.

A mean is a poor summary of a media library. A collection of 200,000 photographs might be mostly compressed frames of 4 MB with a few thousand panoramas and composites in the hundreds, and the mean sits somewhere neither describes. The total is still correct, but any conclusion drawn about a subset — a year, a project, a camera — will be wrong in a way the total conceals.

The improvement that costs nothing is to take the total occupied size directly rather than multiplying a count by an average. Every storage tool will report the total for a directory tree, and that figure includes the block rounding and the sidecars already. Use the average only for forecasting what has not been created yet, where it is the only information available.

An archive is rarely stored once. The common backup discipline keeps three copies on two kinds of media with one held off-site, which turns a 1.46 TiB library into something over 4 TiB of committed capacity before any of it is versioned. Snapshots add further, and a snapshot regime that retains monthly points for a year can hold several times the live size depending on how much of the collection changes.

Estimates built from file sizes almost always describe the primary copy only, because that is the one somebody measured. Writing the multiplier explicitly — live size, times copies, plus snapshot retention — turns a plausible-looking figure into one that can be argued with. It also makes obvious which lever to pull when the total is unaffordable, which is usually the retention schedule rather than the resolution the files were captured at.

Whatever the calculation was done in, state the result in the unit the pool reports, because that is the figure somebody will compare it against next week. A plan expressed in decimal terabytes against a dashboard showing tebibytes needs a conversion every time it is checked, and the conversion is exactly what stops being done once the plan is a few months old.

Where both numbers have to appear — a purchase in decimal terabytes and a fill level in tebibytes — write both, labelled, on the same line. Three terabytes of new disk is 2.73 TiB of pool, and a plan that carries both figures cannot be misread by whoever picks it up after you.