Gibibyte to Block

GB (gigabyte) = 10⁹ bytes = 1,000,000,000 bytes (SI decimal). GiB (gibibyte) = 2³⁰ bytes = 1,073,741,824 bytes (IEC binary). GiB is 7.37% larger. This is why a 1 TB hard drive labelled by the manufacturer (using 10¹² bytes) appears as approximately 931 GiB in Windows or Linux (which divide by 1,073,741,824). Neither value is wrong; they use different counting systems.

Early PC games (1990s) fit on a few floppy disks — under 10 MiB. CD-era games (late 1990s) reached 650 MiB. DVD-era titles hit 4–8 GiB. Modern AAA games like Call of Duty or Flight Simulator now exceed 100–200 GiB due to uncompressed 4K textures, high-fidelity audio in multiple languages, and pre-rendered cinematics. The growth rate has outpaced Moore's Law: storage needs roughly double every 2–3 years for top-tier games, driven primarily by texture resolution increases that scale quadratically with pixel count.

A module sold as "16 GB" RAM by manufacturers means 16 × 10⁹ = 16,000,000,000 bytes? No — RAM is actually built in binary powers. A "16 GB" RAM module contains exactly 2³⁴ = 17,179,869,184 bytes = 16 GiB. In this case, the manufacturer is using "GB" to mean GiB — unlike hard drives, where manufacturers genuinely use decimal GB. RAM capacities are always powers of 2 in gibibytes.

A 512 GB SSD (decimal, as labelled by the manufacturer) holds 512,000,000,000 bytes. Divide by 1,073,741,824 to get GiB: 512,000,000,000 ÷ 1,073,741,824 ≈ 476.8 GiB. After OS overhead and firmware reserved space, the usable capacity shown in the OS is typically 450–465 GiB for a nominally 512 GB drive.

Yes — GiB is the technically correct unit for binary memory. RAM, CPU cache, and GPU memory are all physically organized in powers of 2, making GiB the natural unit. The JEDEC memory standard (the body that defines RAM specifications) officially uses the IEC GiB notation, even though product packaging often says "GB" for commercial reasons. In engineering and OS development contexts, GiB is the preferred term.

Modern hard drives (2011+) and SSDs use 4,096-byte (4 KiB) physical sectors — known as "Advanced Format" or AF. Legacy drives used 512-byte sectors. Filesystems (NTFS, ext4, APFS) typically use 4 KiB logical block sizes to match physical sectors, which avoids the performance penalty of misaligned writes. Enterprise SSDs may use larger block sizes (16 KiB or more) for better parallelism.

Cloud block storage services (AWS EBS, Azure Managed Disks, GCP Persistent Disk) use I/O block sizes typically of 4 KiB or 16 KiB. Performance is measured in IOPS (I/O operations per second) and throughput (MB/s) — both depend on block size. A throughput-optimized workload (sequential video) benefits from large blocks; an IOPS-optimized workload (database random reads) uses small blocks.

Filesystems allocate disk space in whole blocks. On a system with 4 KiB blocks, every file — no matter how small — occupies at least 4,096 bytes. A directory of 10,000 small configuration files (each 100 bytes of content) uses 40 MB of disk space (10,000 × 4,096 bytes) rather than 1 MB (10,000 × 100 bytes). This is called "block slack" or "internal fragmentation".

Disk blocks (filesystem blocks) are typically 512 bytes to 4 KiB. Database blocks (database pages) are the unit of I/O for a database engine — typically 8 KiB (PostgreSQL, SQL Server), 16 KiB (MySQL InnoDB), or 32 KiB (Oracle, configurable). Database blocks usually align to multiples of disk blocks for efficiency. Reading one database page may involve reading 2–8 disk blocks.

RAID stripe size (or chunk size) is the amount of data written to each drive before moving to the next drive in the array — typically 64 KiB to 512 KiB. It should be set to match your workload: sequential large-file workloads benefit from larger stripe sizes; random small-block workloads benefit from stripe sizes closer to the filesystem block size. Mismatched stripe and block sizes cause write amplification and reduce RAID performance.