Convert GiB to KiB

A gibibyte is 1,073,741,824 bytes — about 7% more than a gigabyte. Windows measures in gibibytes and labels them GB, which is the whole of the missing-space mystery.

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 gibibyte is 1,048,576 kibibytes, exactly, and 1,048,576 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 GiB is 1,024 of the unit below it; one GB is 1,000. On this page that is the difference between 1048576 KiB and 976562.5 KiB — 7.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 7.4 %. A drive sold in GB holds exactly what the label says; Windows divides by 1,024 instead of 1,000, keeps the decimal name, and reports 976562.5 KiB where the box said 1048576. 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 partition table stores start and length in sectors. LVM stores physical extents. mdadm stores a chunk size in kibibytes. mkfs takes a block count. None of these is the unit in which anybody decides how big a volume should be, so every disk layout involves converting a gibibyte figure down at least once, and usually into two different smaller units within the same session.

The numbers worth having to hand are 1,048,576 KiB, 2,097,152 sectors of 512 bytes, and 262,144 blocks of 4 KiB per gibibyte. All three are exact powers of two, which is convenient and also the reason a wrong answer looks plausible: an off-by-a-factor-of-two error still produces a tidy number, and only checking it against the total capacity will show it up.

For a long time the first partition on a PC disk started at sector 63, because the geometry the BIOS reported put sixty-three sectors on a track and the first track held the boot record. Sixty-three is odd, so every boundary derived from it was odd, and when drives moved to 4 KiB physical sectors while still presenting 512-byte logical ones, every filesystem block landed across two physical ones.

Starting at sector 2048 — one mebibyte in — fixed it by choosing an offset divisible by every granularity in play: 4 KiB physical sectors, 8 KiB and larger flash pages, 512 KiB RAID chunks, 4 MiB LVM extents. The cost is one mebibyte of disk, which at gibibyte scale is a rounding error, and every partitioning tool has defaulted to it for well over a decade. A layout you inherit that starts anywhere else is worth checking before it is extended.

The penalty is a read-modify-write cycle, and it applies to writes rather than reads. A drive with 4 KiB physical sectors cannot write less than one, so a 4 KiB filesystem block that straddles two of them forces the drive to read both, merge in the new data and write both back. On flash the equivalent unit is the erase block and the amplification is larger, because the controller must relocate and eventually erase far more than was written.

None of this appears in a capacity number, a SMART attribute or a df output — the volume works and reports exactly the size it should. It shows up as random write throughput that is a fraction of what the hardware is rated for, and as write amplification that shortens the life of an SSD. Checking is cheap: parted /dev/sda align-check optimal 1 answers directly, and cat /sys/block/sda/queue/optimal_io_size gives the granularity the drive would prefer.

LVM allocates in physical extents of 4 MiB by default, so a 100 GiB logical volume is 25,600 extents and any size that is not a multiple of 4,096 KiB rounds up to one. That is why lvcreate -L 10G and lvcreate -L 10GiB can produce volumes of the same size while lvcreate -l 100%FREE produces something that looks arbitrary — it is exact in extents and untidy in gibibytes.

RAID adds another. mdadm defaults to a 512 KiB chunk, and a stripe across n data drives is n chunks wide, so a five-drive RAID 5 has a 2 MiB stripe. Filesystem creation should be told about it: mkfs.ext4 takes stride and stripe-width in filesystem blocks, and getting them right lets full-stripe writes avoid the parity read. All of these are kibibyte-level decisions taken underneath a volume size chosen in gibibytes.

The safest habit is to give the suffix and let the tool convert. parted accepts KiB, MiB, GiB and TiB explicitly, and parted -a optimal will place the boundary on the right granularity without being told. sfdisk takes sizes with K, M and G suffixes that are binary. mkfs.ext4 takes a block count, so a size in gibibytes has to become 262,144 blocks per GiB, and getting that one wrong produces a filesystem that fits and does not fill the partition.

Where a bare number is unavoidable, write the gibibyte figure in a comment or a commit message next to it. A layout script full of numbers like 2097152 and 209715200 is correct and completely opaque, and the next person to change it will convert one of them and not the other. The arithmetic is exact in both directions; the documentation is what goes missing.

parted print in its default unit rounds to three significant figures, and fdisk -l prints a human-sized string. Both are for reading. When the size is going to be used — to check that two partitions match across a mirror, to work out whether a replacement disk is large enough, to size a dd copy — switch the tool to sectors and take the exact integer. parted unit s print and blockdev --getsz both give it.

This matters most when replacing a failed drive in an array. Two drives sold as the same capacity can differ by a few mebibytes, and a mirror will not accept a member smaller than the existing one. The convention that avoids the problem is to leave a deliberate gap — partition to a round gibibyte figure a little below the disk's true size — so the exact sector count of the next drive never has to match.

A 100 GiB partition is 104,857,600 KiB, and a fresh ext4 filesystem on it will report noticeably less. The journal takes a fixed amount, commonly 128 MiB on a volume this size. Inode tables are allocated up front at one inode per 16 KiB by default, at 256 bytes each — about 1.6 GiB on a 100 GiB volume. Five per cent is reserved for root by default, which tune2fs -m can reduce on a data volume where nothing needs the reserve.

That is close to seven gibibytes accounted for before a byte is written, and none of it is loss — it is the structures that make the filesystem work, plus a reserve that exists so a full disk does not become an unrecoverable one. Where the volume will hold a small number of large files, mkfs.ext4 -T largefile cuts the inode count sharply and gives most of the inode table back.