Convert TB to MiB

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.

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

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

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.

Chunk sizes are chosen by software and are therefore powers of two: 4 MiB extents in a volume manager, 128 MiB blocks in a distributed file system, part sizes in multiples of 8 or 16 MiB for large uploads. Capacities are set by hardware and commerce and are therefore decimal. Every time one is divided by the other the answer has a fraction in it, and the fraction has to go somewhere.

The conversion is a single division: terabytes times 1,000,000,000,000, divided by 1,048,576, gives 953,674.31640625 MiB per terabyte. From there, dividing by the chunk size gives the count. The exactness matters less than the direction — the mebibyte figure is always about 4.9 per cent below what a naive division by a million would suggest, and a chunk count derived the naive way is correspondingly too high.

Large object uploads are split into parts, and services that support them cap the number of parts — commonly at 10,000. That cap turns the chunk size into a constraint rather than a preference: a one-terabyte object needs parts of at least 100,000,000 bytes, which is 95.37 MiB, or the upload cannot complete. A five-terabyte object needs parts of at least 476.84 MiB by the same arithmetic.

The usual response is to round the part size up to the next power of two and accept the extra headroom. A 128 MiB part size handles a terabyte in 7,451 parts and comfortably covers anything up to about 1.34 TB before the ceiling is met again. Choosing 100 MB instead would work numerically and align with nothing underneath it, which is why the binary figure is the one that gets picked.

A terabyte is 7,450.58 blocks of 128 MiB: 7,450 whole ones and a remainder of 74.32 MiB. Systems that allocate whole blocks will reserve 7,451, leaving the last one a little over two-fifths empty — a rounding cost of about 54 MiB against a terabyte, which is 0.005 per cent and not worth a thought on a single large file.

The same arithmetic at the other end of the file-size distribution is where it bites. A block size of 128 MiB storing a million files of 2 MiB each allocates a full block per file, consuming 122 TiB of capacity for 1.9 TiB of content. Block size is chosen for the workload rather than the capacity, and converting the capacity is the step that shows what a given choice will actually cost.

Volume managers allocate in extents, typically 4 MiB, so a terabyte of logical volume is 238,418.58 extents and will be rounded to a whole number of them. Striped layouts add a second alignment: a stripe width that is a multiple of the extent size keeps every stripe on a boundary, and one that is not produces reads that straddle two devices where one would have served.

None of this is visible in a capacity figure and all of it follows from converting one. Working the decimal size into mebibytes and then into the allocation unit is what shows whether the chosen geometry divides cleanly or leaves a partial unit at every level. Where it does not divide cleanly, the usual fix is to size the volume in binary units and let the decimal figure be whatever it turns out to be.

Because 1,000,000,000,000 and 1,048,576 share only factors of two — the decimal figure carries twelve of them and the binary one twenty — a terabyte is never a whole number of mebibytes and never will be. Any capacity that does divide evenly into binary chunks was specified in binary units in the first place, which is a useful thing to notice about a number somebody has handed you.

That is why storage software tends to present sizes in binary units even when the hardware beneath was sold decimally: it is choosing the representation in which its own arithmetic is exact. The conversion in this direction exists mainly for the moment when a decimal figure from outside the system has to be reconciled with the binary one inside it.

A terabyte is a little under a million mebibytes, which makes the mental version easy: divide a million by the chunk size in MiB and take five per cent off. For 128 MiB that is about 7,800 less five per cent, or roughly 7,400, against 7,450.58 exact. For 64 MiB it is about 14,900, and for 16 MiB about 59,600.

The estimate is good enough for the question chunk counts are usually asked for, which is whether a part limit will be hit. If the rough figure lands within twenty per cent of a 10,000-part ceiling, do the arithmetic properly; if it is a factor of two clear in either direction, the estimate has already answered it and the exact number will not change the decision.

Chunk size trades two costs against each other. Small chunks mean a large count, more requests, more bookkeeping and a part-count ceiling that arrives sooner; large chunks mean fewer requests and a bigger loss when one fails, because a failed chunk is retried in full. At 128 MiB a dropped connection costs up to 134 million bytes of repeated transfer, and on an unreliable link that repetition can outweigh the overhead the large chunk was chosen to avoid.

Converting the total capacity is what makes the trade visible. A terabyte at 16 MiB a chunk is 59,605 chunks, at 128 MiB it is 7,451, and at 512 MiB it is 1,863. The middle figure is the usual compromise not because of any property of the number but because it sits between a part-count ceiling of 10,000 and a retry cost measured in minutes.

A capacity written without its chunk size is only half a specification. Two systems holding a terabyte in 4 MiB extents and in 128 MiB blocks behave differently under fragmentation, under partial writes and under recovery, and the capacity figure is identical in both. Storage plans that carry only the terabyte number lose the part of the design that actually determined the performance.

The practical form is a line giving the decimal capacity, the binary equivalent, the chunk size and the resulting count: one terabyte, 953,674.32 MiB, 128 MiB blocks, 7,451 blocks. Every figure there is derivable from the others, which is the point — anybody reading it later can check the arithmetic instead of re-deriving the assumptions.