How storage capacity is calculated in binary — and why manufacturers and OS never agree
At its core, storage capacity calculation is a binary multiplication problem. The total capacity of any storage device is: Total Bytes = Number of Addressable Units x Unit Size. For a hard drive, that's Total = Sectors per Track x Heads x Cylinders x Bytes per Sector. For a memory chip, it's Total = 2^(Address Lines) x Data Bus Width / 8. In every case, the numbers are powers of two.
I've calculated countless storage capacities for system design. A SSD with 8 NAND dies, each having 128 GB of 3D TLC NAND organized in 16 planes per die with 2^18 blocks per plane: the binary math cascades from the chip level up. The total raw capacity is 8 x 128 GB = 1 TB, but after over-provisioning (typically 7-28% reserved for wear leveling and bad block management), the usable capacity might be 960 GB or 1,000 GB depending on the manufacturer's decimal or binary labeling choice.
This is the most pervasive binary confusion in consumer computing. Manufacturers (drive makers, flash vendors) use decimal: 1 GB = 1,000,000,000 bytes = 10^9 bytes. Operating systems (Windows, most Linux tools) use binary: 1 GB = 1,073,741,824 bytes = 2^30 bytes.
The gap grows with each unit:
I always advise clients to use the raw byte count when comparing devices — it's the only unambiguous measure.
One of the most elegant properties of binary addressing is that adding one address bit doubles the addressable capacity. This is why memory capacities are always powers of two, and why the jump from 32-bit to 64-bit computing was so transformative.
Here's how address bits map to capacity, which I use when designing embedded systems:
Each additional bit doubles the maximum capacity. This exponential scaling is why we went from 4 GB (32-bit) to effectively unlimited (64-bit) in a single architectural generation.
When configuring RAID arrays, I deal with binary capacity calculations constantly. The usable capacity depends on the RAID level and the number of drives:
In a real scenario from a server I managed: four 4 TB drives (advertised) in RAID 5. Each drive has 4,000,000,000,000 bytes. The array capacity = (4 - 1) x 4,000,000,000,000 = 12,000,000,000,000 bytes. But the OS converts this to binary: 12,000,000,000,000 / 1,073,741,824 = 11,175 GiB = 10.9 TiB — not 12 TB as the sum of labels would suggest. Always use careful binary math.
In my systems architecture work, I frequently calculate maximum addressable storage for different configurations. The formulas are pure binary:
The practical limit for current hardware is 256 TiB (48-bit addressing). For enterprise storage arrays, LBA size is typically 64-bit, providing headroom well beyond any current practical capacity.
RAID controllers often reserve space for metadata, and this overhead affects usable capacity in ways that aren't obvious. I've seen a 12-drive RAID 6 array where the "expected" usable capacity was (12 - 2) x 4 TB = 40 TB, but the actual usable capacity was about 39.2 TB due to controller metadata and stripe alignment overhead.
The stripe size itself is a binary decision. A 64 KB stripe on a RAID 5 array with 4 drives means each stripe = 4 x 64 KB = 256 KB, but only 192 KB of data per stripe (the fourth chunk is parity). File system journaling adds more overhead. Ext4 with default 4 KB blocks and a 128 MB journal uses exactly 32,768 blocks for metadata before any user data is stored. Every one of these numbers is a binary calculation: journal_blocks = journal_size_bytes / block_size = 134,217,728 / 4,096 = 32,768.
Key Formula: Capacity = 2^(address_bits) x unit_size · Manuf vs OS: divide labeled GB by 1.074 to get GiB · RAID 5: (N-1) x smallest · RAID 6: (N-2) x smallest · Each extra address bit doubles capacity
Open the Binary Code Decoder in a new tab and enter some binary patterns to see the results instantly. All conversions happen in your browser — no data is sent to any server.