Convert GB to KiB

A gigabyte is a billion bytes in the decimal sense used by drive manufacturers, phone plans and video sizes.

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.

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

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 KiB is 1,024 of the unit below it; one kB is 1,000. On this page that is the difference between 0 GB and 0 GB — 2.4 % — 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 2.4 %. A drive sold in kB holds exactly what the label says; Windows divides by 1,024 instead of 1,000, keeps the decimal name, and reports 0 GB 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.

A gigabyte is 1,000,000,000 bytes and a kibibyte is 1,024, so the ratio is 976,562.5 exactly. The half is not a rounding artefact and does not disappear with more precision: a decimal gigabyte is not a whole number of kibibytes, because 10 to the ninth has no factor of 1,024 in it. Every odd gigabyte figure converted to blocks lands on a half.

That matters wherever the receiving tool wants an integer, which is most of them. Rounding up gives the user slightly more than was promised, rounding down slightly less, and truncation — which is what a naive integer division does — quietly does the second. For a quota it is a difference of 512 bytes and nobody notices; for an assertion in a test it is the difference between passing and not.

GNU df with no arguments prints 1 KiB blocks. du -k does the same. quota, repquota and setquota account in 1 KiB units. vmstat reports memory in 1,024-byte blocks. These interfaces were designed when a disk was measured in megabytes and a block count fitted comfortably in a column, and they have not changed because every script that parses them would break.

The result is that a modern volume is described by a nine-digit number. A 2 TB filesystem is 1,953,125,000 blocks. That is unreadable by design and precise by accident, and it is the reason this conversion is done far more often by scripts than by people — which in turn is why getting the constant right once, in a variable with a name, is worth more than remembering it.

A quota is nearly always agreed in decimal gigabytes, because that is the unit the agreement was written in: fifty gigabytes per user, five hundred per project. setquota wants blocks. The multiplication is 976,562.5 per gigabyte, so fifty gigabytes is 48,828,125 blocks and five hundred is 488,281,250 — both whole, because the half doubles into a whole at every even figure.

The soft and hard limits then need the same treatment and usually get different ones. A soft limit derived from a round gigabyte figure and a hard limit set by adding "ten per cent" to the block count are two conversions with two rounding decisions, and the gap between them stops being the ten per cent anybody intended. Convert once, then compute both limits from the block figure.

Quota accounting works in 1 KiB units almost universally. The filesystem underneath allocates in 4 KiB blocks by default on ext4 and most modern volumes. Those are two different quantities and a user consumes the second while being charged in the first, so quota usage is reported as four times the block count for every file that occupies a single allocation unit.

For a home directory of ordinary documents the effect is a few per cent. For a directory of many small files it is the dominant term: a thousand 1 kB files are a megabyte of content and about four megabytes of quota. When somebody insists they are under their limit and the tool disagrees, this is the first thing to check, and it has nothing to do with the decimal-versus-binary question at all.

GNU coreutils read the BLOCK_SIZE environment variable, and DF_BLOCK_SIZE and DU_BLOCK_SIZE override it per tool. Setting POSIXLY_CORRECT changes the default block from 1,024 bytes to 512, halving every figure the tools print. All of this is documented, none of it is visible in the output, and all of it travels with a shell profile rather than with a command.

The practical consequence is that a block count pasted into a ticket is not self-describing. Two administrators running the same df on the same host can produce figures that differ by a factor of two, and the argument that follows is about the filesystem rather than about the environment. Passing an explicit --block-size when a number is going anywhere other than your own screen removes the whole class of problem.

The block figures worth recognising are the round ones. 1 GB is 976,563 blocks rounded, 10 GB is 9,765,625, 100 GB is 97,656,250, 1 TB is 976,562,500. The leading digits are the same at every scale — 9765625 — which makes the magnitude the only thing to read, and that is a digit count rather than a value.

It also makes a common error easy to spot. A figure beginning 1048 or 1073 is a binary-to-binary conversion that has been done with the wrong pair of units: 1,048,576 blocks is a gibibyte, not a gigabyte. If a block count starts with a 9 the units crossed systems as intended; if it starts with a 1 somebody divided by the wrong thing.

A capacity quoted in decimal gigabytes almost always originated outside the machine: a drive label, a service tier, a contract, a purchase order. It is the number somebody was sold. The block count is the number the machine enforces, and between them sit the filesystem overhead and the reserved blocks that neither party mentioned.

So a quota of exactly 976,562,500 blocks on a "1 TB" volume will not be attainable, because the volume does not present a full terabyte of usable space once its own structures are allocated. Setting per-user quotas that sum to the nominal capacity is the standard way to oversubscribe a filesystem without meaning to, and it is a unit-conversion problem only in the sense that the units are what made it look correct.

Before 1 KiB blocks there were 512-byte ones, and they have not gone away. POSIX specifies 512 as the unit for df and du output, which is why setting POSIXLY_CORRECT halves every figure those tools print. tar counts in 512-byte records. Disk geometry used 512-byte sectors for decades, and drives that moved to 4,096-byte physical sectors still present 512-byte logical ones for compatibility. ls -s reports allocated blocks, historically in units of 1,024 on GNU systems and 512 elsewhere.

The practical result is that a block count is meaningless without its block size, and the block size is a property of the tool, the platform and the environment rather than of the filesystem. A figure of 1,953,125,000 is a 2 TB volume in 1 KiB blocks and a 1 TB volume in 512-byte ones, and nothing about the number distinguishes the two. Recording the unit alongside a block count is not pedantry here; it is the only thing that makes the number interpretable at all.