Nibble to Block

A nibble is 4 bits, or half a byte. It encodes one hexadecimal digit (values 0–15, represented as 0–9 and A–F). Nibbles are important in BCD (binary-coded decimal) encoding, where decimal digits are packed two per byte (each digit occupying one nibble). Packed BCD is used in financial systems and legacy databases to represent decimal numbers without floating-point rounding errors.

Hexadecimal (base 16) maps perfectly to nibbles because 4 bits can represent exactly 16 values (2⁴ = 16). One byte = two nibbles = two hex digits. A byte value of 0xFF (255 in decimal) is two nibbles: F (1111) and F (1111). This mapping makes hexadecimal the natural notation for expressing binary data — programrs use hex because one hex digit always represents a fixed number of bits.

Binary-Coded Decimal (BCD) encodes each decimal digit (0–9) as a 4-bit binary value (nibble). Two decimal digits fit in one byte using "packed BCD". For example, the decimal number 47 is stored as 0100 0111 in packed BCD — each nibble holds one digit. BCD avoids the rounding errors of binary floating-point, which is why it is used in financial software, calculators, and legacy banking systems.

A nibble = 4 bits (1 hex digit). A byte = 8 bits (2 hex digits, 2 nibbles). A word = typically 16, 32, or 64 bits depending on the processor architecture (see the "word" unit for details). These are the fundamental granularities of digital data: nibble for hex/BCD, byte for text and addressing, word for native processor arithmetic.

Nibbles are rarely referenced directly in modern high-level programming but remain fundamental at the hardware level. Embedded systems, FPGA design, network packet parsing, and hardware description languages (VHDL, Verilog) regularly manipulate nibbles. The nibble is also the key concept behind hexdump utilities — the canonical way to inspect raw binary files and network packets.

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.