Convert TiB to KiB

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 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 tebibyte is 1,073,741,824 kibibytes, exactly, and 1,073,741,824 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 TiB is 1,024 of the unit below it; one TB is 1,000. On this page that is the difference between 1073741824 KiB and 976562500 KiB — 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 976562500 KiB where the box said 1073741824. 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.

Thirty bits separate the two units, so a tebibyte becomes 1,073,741,824 kibibytes and any realistic quota becomes a number nobody can read at a glance. Two tebibytes is 2147483648, five is 5368709120, ten is 10737418240. These are the values that go into the field, and the field will accept any integer you give it — including one with an extra digit, which is the mistake that actually happens.

The habit that catches it is counting digits rather than reading the number. A mebibyte is four digits of kibibytes, a gibibyte seven, a tebibyte ten, a pebibyte thirteen. Every unit adds three, near enough, so a quota intended as single-digit tebibytes should have ten or eleven digits and anything else is wrong by an order of magnitude before you look at the value itself.

Block limits in setquota, edquota and repquota are counts of 1,024-byte units, whatever the underlying filesystem's block size happens to be. That decoupling is deliberate: a quota set on an ext4 volume with 4 KiB blocks and one set on a filesystem with 64 KiB blocks mean the same amount of space, and moving a home directory between them does not silently change everybody's allowance.

It does mean the reported figures do not match the filesystem's own accounting unit, so a user occupying 1,000 blocks of 4 KiB shows as 4,000 quota blocks. XFS keeps its own quota implementation with the same unit and a different toolchain — xfs_quota -c 'limit bhard=2t user=alice' accepts a suffix and does the arithmetic itself, which is the better route whenever it is available.

The soft limit is a warning with teeth. A user over it keeps working while a grace period runs — seven days by default — and when the grace expires the soft limit starts behaving as a hard one. The hard limit is immediate: the write returns EDQUOT and the application usually reports it as a disk-full error, which sends the user to check free space and find plenty of it.

The gap between the two is where the design decision lives. A soft limit at 1.8 TiB and a hard limit at 2 TiB gives 214,748,364 kibibytes of runway and a week to use it, which is enough for somebody to notice a warning and clear space. Setting both to 2 TiB gives no warning at all, and the first anybody hears about it is a failed job. Where the two figures are equal in a quota table, it is usually because whoever set them converted one number and copied it twice.

Every quota has a second pair of limits counting files rather than kilobytes, and they are independent. A user well inside a 2 TiB block quota can still be refused a write because they have reached their inode limit, and the error is the same disk-quota message with no indication which ceiling was hit. quota -s shows both, and it is the first thing to check when a user insists they have space.

The inode limit exists because inodes are a fixed resource allocated when the filesystem was created and cannot be added later. A single account creating tens of millions of tiny files can exhaust them while using a negligible share of the block quota, at which point nobody on the volume can create a file. Setting an inode limit is therefore protective of the filesystem rather than of the user, and it does not need to be converted from anything.

Some tools in this area take a suffix and some do not, and knowing which is worth more than knowing the conversion. xfs_quota accepts k, m, g and t and treats them as binary. Recent setquota builds accept the same on the command line. edquota drops you into an editor on a table of bare integers, and any value written there is kibibytes. ZFS sidesteps the question entirely — zfs set quota=2T is a dataset property with its own parser.

Where the bare integer is unavoidable, record the tebibyte figure next to it. A quota table containing 2147483648 and 2147483648 is correct and unreviewable; the same table with a comment saying 2 TiB soft, 2 TiB hard invites somebody to notice that the soft limit should have been lower. The arithmetic is exact and instant either way, so the only thing at stake is whether the next reader can tell what was intended.

A quota is a ceiling and a reservation is a floor, and the second is the harder one to size. ZFS reservations, XFS project quotas used as guarantees, and thin-provisioned volumes with a guaranteed minimum all set aside blocks that will not be given to anybody else. A 2 TiB reservation removes 2,147,483,648 kibibytes from the pool's available figure the moment it is set, before a single byte has been written into it.

That is what makes an over-reserved pool report itself full while appearing nearly empty. The sum of reservations across datasets can approach the pool size with almost no data present, and every tool that reports free space is telling the truth from its own point of view. Working the reservations out in kibibytes, summing them, and comparing that against the pool total in the same unit is the check that catches it — done in tebibytes, the rounding hides several hundred gibibytes of commitment.

A block quota controls how much a user stores and nothing about how much they write. Somebody repeatedly creating and deleting large temporary files stays inside a 2 TiB quota indefinitely while generating enormous write amplification, wearing flash and filling snapshots with churn. If the concern is throughput or device life rather than capacity, the quota field is not the lever and no conversion will make it one.

Snapshots complicate the ceiling in the other direction. On a copy-on-write filesystem, deleted data still referenced by a snapshot is still charged somewhere, and depending on how the quota is scoped it may still be charged to the user who deleted it. A user who has removed a tebibyte of files and seen no change in their usage is generally looking at that, and the fix is a retention policy rather than a larger number in the block field.