Word to Block

A word's size depends on the CPU architecture. In x86/x64 (Intel/AMD) documentation: word = 16 bits, DWORD = 32 bits, QWORD = 64 bits. In ARM 32-bit: word = 32 bits. In most modern 64-bit systems (excluding x86 documentation): word = 64 bits. When reading technical documentation, always check the architecture's definition, as "word" is not a universal fixed size.

In Windows API documentation and x86 architecture, a DWORD (Double Word) = 32 bits = 4 bytes, capable of holding values 0–4,294,967,295 (unsigned) or -2,147,483,648 to 2,147,483,647 (signed). DWORD is the most common fixed-width integer type in the Windows API, used for flags, handles, and return codes. The equivalent in modern C/C++ is uint32_t (unsigned) or int32_t (signed).

A CPU's word size determines: (1) the maximum addressable memory — a 32-bit CPU addresses up to 4 GiB (2³² bytes); a 64-bit CPU addresses up to 16 EiB (2⁶⁴ bytes); (2) the precision of integer arithmetic — a 64-bit word handles numbers up to ~18.4 × 10¹⁸ in a single instruction; (3) performance — operations on data smaller than the word size may require extra sign-extension instructions on some architectures.

Modern x86-64 CPUs (Intel Core, AMD Ryzen) have 64-bit general-purpose registers, so their native word size is 64 bits for most operations. However, x86 documentation maintains the legacy definition: "word" = 16 bits, DWORD = 32 bits, QWORD = 64 bits. This creates a confusing terminology mismatch between the architectural naming convention and the physical register size.

Memory alignment means storing data at addresses that are multiples of the data's size. A 32-bit word should be stored at an address divisible by 4 (bytes); a 64-bit word at an address divisible by 8. Misaligned access is either forbidden (causes a CPU fault) or penalised (requires two memory reads instead of one). Compilers automatically align variables; manual struct packing can create misalignment that causes subtle performance issues or crashes on strict architectures.

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.