Convert TiB to 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.

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.

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.

Every transfer estimate is a division, and its two inputs come from different unit systems. The volume is reported by whatever holds the data — a backup repository, an array, a filesystem — and those all count in powers of 1,024, so the figure arrives in tebibytes. The rate comes from a network or a device specification, and those are decimal without exception.

Dividing one by the other without converting produces an answer nearly ten per cent too optimistic, which on a migration window is the difference between finishing inside a maintenance period and not. One tebibyte is 1,099,511.63 MB, so the honest first step is to turn the volume into decimal megabytes and only then to divide by the rate.

Before any of the binary arithmetic matters, there is a much larger trap in the same sentence. Link speeds are quoted in bits per second and transfer rates in bytes per second, and a byte is eight bits. A 1,000 Mbit/s link moves at most 125 MB per second; a 100 Mbit/s link 12.5; a 10 Gbit/s link 1,250. The distinction is carried entirely by the case of a single letter.

Getting that wrong is an eight-fold error, roughly seventy times larger than the decimal-versus-binary gap this page is otherwise about. It is worth resolving first and explicitly: write the rate down in MB per second, with the working, before touching the volume. An estimate that is out by a factor of eight is usually caught; one that is out by ten per cent is not, which is why both steps deserve to be visible.

The arithmetic is short once both sides are decimal. One tebibyte is 1,099,512 MB; at 100 MB per second that is 10,995 seconds, or 3 hours 3 minutes. Ten tebibytes at the same rate is 30 hours 32 minutes. At 1,250 MB per second — a ten-gigabit link running at its theoretical ceiling — ten tebibytes is 2 hours 27 minutes.

Those figures are floors, and they should be labelled as such wherever they are quoted. They assume a single continuous stream at the full rate with no per-file cost, which no real transfer achieves. Presenting a floor as an estimate is how a migration window gets sized at exactly the number that cannot be met, and adding the qualifier costs one word.

The gap between the arithmetic and the clock is dominated by file count rather than by volume. Every file costs a create, a metadata write and, over a network protocol, at least one round trip; a million small files can spend more time on those than on moving their contents. A single large file at the same total size will run close to the link rate. Two transfers of identical size can therefore differ by an order of magnitude in duration.

The other subtractions are steadier and easier to allow for. Protocol overhead takes a few per cent. Encryption and checksums cost CPU that may or may not be the bottleneck. The receiving storage has a write ceiling that is frequently lower than the network’s. Parallelism recovers much of this and introduces its own limit, since a hundred concurrent streams do not go a hundred times faster.

Where a transfer leaves a provider, the charge is per decimal gigabyte and the meter is theirs. A repository reported as 10 TiB is 10,995 GB of billable egress if all of it moves, which is 9.95 per cent above the round figure anybody would estimate from the tebibyte number. On a large migration that percentage is a line item somebody has to explain.

The provider’s meter also counts things your own figure does not: retries, protocol overhead, and any traffic the tooling generates while listing and verifying. Those are usually small against a bulk transfer and are not always small against a job that restarts. Estimating from the converted volume and treating the difference as a contingency is more honest than presenting a converted figure as the bill.

Long transfers are interrupted, and what gets re-derived after an interruption is where estimates drift. The remaining volume is usually reported by the source in tebibytes again, the rate observed so far is in megabytes per second, and the person doing the arithmetic at two in the morning is the one most likely to divide the two directly. The correction is the same 9.95 per cent, applied to a smaller number, in a worse frame of mind.

Writing the conversion into the runbook rather than the estimate is what prevents that. A line reading "remaining TiB × 1,099,512 = MB; ÷ observed MB/s = seconds" takes one line, is checkable, and produces the same answer at two in the morning as it did at the planning meeting.

The figures that make an estimate auditable are the intermediate ones. Volume in TiB as reported by the source; the same volume in MB; the rate in MB per second with the bit-to-byte conversion shown if there was one; the theoretical floor; the assumed efficiency; the resulting window. Six lines, and each of them is a number somebody can challenge without re-deriving the whole thing.

The alternative is a single duration, which is unarguable in the bad sense: when the transfer overruns, nobody can say whether the rate was optimistic, the volume was stale or the units were mixed. Storage and transfer estimates are revisited under time pressure more than any other kind, and that is exactly when a chain of visible steps earns back the minute it took to write.

An estimate that stops at the transfer is usually short by a whole pass. Anything worth migrating is normally worth verifying, and a checksum comparison reads the full volume again at both ends. If the transfer of 10 TiB takes thirty hours, the verification is another read of 10,995,116 MB on each side, bounded by disk throughput rather than by the network and frequently slower than the copy itself on the source.

There are cheaper variants and they are worth choosing deliberately rather than by default. Verifying a sample gives a probabilistic assurance in a fraction of the time. Tools that checksum during the transfer avoid the second read entirely, at some cost in throughput. Trusting the protocol's own integrity checks is defensible for a single hop and much less so for a multi-stage migration. Whichever is chosen, the window has to include it, because discovering it afterwards is how a maintenance period overruns.