Convert MiB to KiB

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 kibibyte is exactly 1,024 bytes. The name was coined in 1998 precisely so that "kilobyte" could go back to meaning 1,000, though the habit never fully took.

Going this way is a multiplication, and by a whole number: one mebibyte is 1,024 kibibytes, exactly, and 1,024 is the definition rather than a measurement that came close.

That makes it one of the few conversions worth doing in your head, and it makes the answer checkable: divide back and you must land on the number you started with, exactly, with no remainder to explain away.

One MiB is 1,024 of the unit below it; one MB is 1,000. On this page that is the difference between 1024 KiB and 976.5625 KiB — 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 976.5625 KiB where the box said 1024. 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.

A surprising number of Unix limits are counted in kibibytes with no way to say so in the value. ulimit -s, ulimit -v and ulimit -m are all kibibytes. The stack, data, memlock and as columns in /etc/security/limits.conf are kibibytes. rsync's --bwlimit defaults to kibibytes per second when given a bare number. Disk quota blocks are kibibytes. In each case the field holds an integer and the unit is implied by the manual page rather than by anything you can type.

That is why this conversion is a writing operation rather than a reading one. You know you want an 8 MiB stack or a 20 MiB/s cap; the field wants 8192 or 20480; and the only feedback on getting it wrong is a segfault, a transfer running at a thousandth of the intended rate, or a limit so large it may as well be absent. Multiply by 1,024, and write the mebibyte figure in a comment beside it.

Every mebibyte figure multiplied by 1,024 lands on a multiple of 1,024, and every power-of-two mebibyte figure lands on a power of two: 8,192, 16,384, 65,536, 262,144, 524,288, 1,048,576. Reading a configuration file and finding 8192 tells you somebody thought in mebibytes; finding 8000 tells you somebody thought in megabytes and the field is 2.4 per cent smaller than intended.

The discrepancy rarely matters on its own and reliably matters in aggregate. A limit set to 8000 rather than 8192 is 192 KiB short, which no single process will notice; a buffer sized 500,000 rather than 524,288 across a fleet is a measurable throughput difference, and it is impossible to attribute afterwards because nothing failed. Round numbers in binary fields are the cheapest correctness signal available.

Where a tool accepts a suffix, using it removes the arithmetic and documents the intent in the same stroke. sort -S 512M, curl --limit-rate 200K, dd bs=4M, rsync --bwlimit=20M all read correctly a year later, which sort -S 524288 does not. The suffix also survives somebody deciding to double the value, which a hand-multiplied integer generally does not.

The exception is anything that will be parsed by something other than the tool itself. Monitoring, config management and audit tooling frequently compare these fields as plain integers, and a mixture of 524288 and 512M across a fleet defeats the comparison. Where that applies, pick the integer form deliberately and keep it consistent rather than letting each host record whichever the author preferred.

GNU dd is the clearest case because it spells both out: bs=1K is 1,024 bytes, bs=1KB is 1,000, and bs=1KiB is accepted as a synonym for the first. Nothing about the syntax hints at which you have typed, and a dd run with the wrong one copies the right data in slightly wrong-sized pieces, which usually works and occasionally does not when the destination is a device with a hard block size.

Elsewhere the rule of thumb is that anything measuring a rate is likely to be decimal and anything measuring memory is likely to be binary, because network engineering standardised on powers of ten long before the kibibyte had a name. A 100 Mbit link is 100,000,000 bits per second and not 104,857,600, so a bandwidth cap converted from a link speed should be worked out in decimal and only then turned into the kibibytes the tool wants.

The default 8 MiB stack shows up as 8192 because that is the unit ulimit -s counts in, and it is worth converting rather than copying because the figure is per thread rather than per process. A JVM or a connection-per-thread server with several hundred threads reserves that much address space several hundred times over, which on a 64-bit machine is free and on a 32-bit one exhausts the address space long before it exhausts memory.

Lowering it is a real tuning lever and a real hazard. Setting 512 KiB — the field takes 512 — is enough for most application code and not enough for a deeply recursive parser or anything that puts a large buffer on the stack. The failure is a segmentation fault with no message about limits, so the mebibyte figure is worth recording next to the change; 0.5 MiB explains itself where 512 does not.

PostgreSQL states its memory units as kB, MB and GB and defines them as binary, so shared_buffers, work_mem, maintenance_work_mem and wal_buffers are all kibibyte multiples under decimal-looking labels. SHOW shared_buffers returns the value in the unit it decides is tidiest, and pg_settings holds it in 8 KiB blocks, so the same setting can be read as 128MB, 131072 kB and 16384 blocks without any of them being wrong.

MySQL takes byte counts with optional K, M and G suffixes that are likewise 1,024-based, and reports them in bytes. The practical consequence for both is that a value copied from a tuning guide that quoted megabytes is 2.4 per cent smaller than intended per step of prefix, and 7.4 per cent by the time it reaches gigabyte-sized settings — never enough to notice and always enough to make two servers that were meant to match not quite match.

Multiplying by 1,024 keeps every value that started as a sensible fraction: a half is 512, a quarter is 256, three-quarters is 768, an eighth is 128. Values that came from a decimal calculation do not survive as neatly — 0.1 MiB is 102.4 KiB and 1.3 MiB is 1,331.2 — and the field will take an integer, so a decision has to be made rather than deferred.

Which way to round depends on what the field is. A limit, a cap or a maximum should round down, because the intent is "no more than this" and overshooting defeats it. A buffer, a reservation or a minimum should round up, because a buffer one kibibyte short of a natural boundary can cost an extra round of allocation on every operation. Neither choice matters much; making it consciously is what stops a review from having to work out which was meant.