Section 49: Glossary — Overview

Purpose and Scope

This section is the comprehensive terminology reference for the entire systems knowledge archive, spanning 400+ terms across ten domains: kernel and operating systems, memory systems, storage and filesystems, networking, distributed systems, database internals, security, performance engineering, virtualization and containers, cloud infrastructure, and hardware architecture. Each entry provides a precise technical definition, distinguishes the term from commonly confused neighbors, and cross-references the archive section where the concept is treated in depth. The glossary is designed both for initial learning (what does this term mean?) and for precision review (am I using this term correctly?).

Definitions in this glossary prioritize technical precision over accessibility. Where the community uses a term loosely in multiple senses, the glossary gives the precise original meaning and notes the colloquial variants.

Prerequisites

None. The glossary is a reference, not a sequential reading experience.

Learning Objectives

Upon using this section, the reader will be able to:

Look up any unfamiliar term encountered elsewhere in the archive and obtain a precise definition
Distinguish between commonly confused term pairs (mutex vs semaphore, process vs thread, coherence vs consistency, availability vs durability)
Trace a term back to the domain section where it is treated in depth
Identify the correct technical terminology for a concept they understand informally

Glossary Structure and Scope

GLOSSARY DOMAIN DISTRIBUTION (400+ terms)
==========================================

  Domain                          Approx. Terms
  ─────────────────────────────   ─────────────
  Kernel and OS fundamentals          80
  Memory management                   45
  Storage and filesystems             40
  Networking                          55
  Distributed systems                 50
  Database internals                  35
  Security                            40
  Performance engineering             35
  Virtualization and containers       30
  Cloud infrastructure                25
  Hardware architecture               30
  ─────────────────────────────   ─────────────
  Total                            ~465

Sample Glossary Entries (Illustrating Depth and Precision)

The following samples demonstrate the definition format used throughout the section.

address space — The range of virtual addresses a process can use, from 0 to the maximum virtual address supported by the CPU (2^48 on current x86-64 with 4-level paging). The kernel maps itself into the upper portion of each process's address space (higher-half kernel) and the process's code, data, heap, and stack occupy the lower portion. Not to be confused with physical address space, which is the range of addresses the CPU uses to address physical RAM and MMIO regions. See: Section 11 (Memory Management)

aliasing (memory) — The condition where two different pointers or references refer to overlapping memory regions. Aliasing prevents certain compiler optimizations (the strict aliasing rule in C restricts what types can alias). In hardware, memory aliasing refers to cache aliases: two virtual addresses mapping to the same physical address appearing in the same set of a virtually-indexed physically-tagged (VIPT) cache. See: Section 11; Section 44 (Rust borrow checker)

atomicity — The property that an operation either completes entirely or has no effect; it is never observed in a partially complete state. In concurrent programming: an atomic operation executes without interleaving from other threads. In database transactions: the A in ACID; a transaction's writes are either all applied or none are. The two meanings are related but not identical. See: Section 10 (Synchronization); Section 18 (Database Internals)

barrier (memory) — A processor or compiler instruction that enforces ordering constraints on memory operations. A full memory barrier ensures that all loads and stores before the barrier complete before any loads or stores after it begin. A store barrier (write barrier) ensures only store ordering. A load barrier ensures only load ordering. The exact semantics depend on the CPU's memory model (TSO on x86, relaxed on ARM/POWER). See: Section 06 (CPU Architecture); Section 10 (Synchronization)

buddy allocator — A physical memory allocator that manages memory in power-of-2 sized blocks. To allocate 2^k pages, find the smallest free block of size >= 2^k, splitting larger blocks into "buddies" as needed. On free, merge a freed block with its buddy if the buddy is also free, propagating upward. Linux uses the buddy allocator for physical page management. Fast but suffers internal fragmentation and cannot allocate large physically contiguous regions efficiently. See: Section 11 (Memory Management)

cache coherence — The property that all processors in a multiprocessor system observe a consistent view of memory: if processor A writes to address X and processor B subsequently reads address X, B sees A's write. Achieved via coherence protocols (MESI, MOESI, MESIF) implemented in hardware. Coherence is a per-address property; consistency is a system-wide ordering property. See: Section 06 (CPU Architecture)

capability (security) — An unforgeable token that grants the holder specific rights to a specific resource. Unlike UNIX discretionary access control (DAC), capabilities are not ambient: a process can only access a resource if it holds a capability for that resource. Capabilities can be passed between processes (delegation) but cannot be forged or stolen. Used in seL4, Fuchsia/Zircon, CHERI hardware. See: Section 26 (Security); Section 42 (Future of OSes)

context switch — The kernel operation that saves the CPU state (registers, program counter, stack pointer) of one thread or process and restores the state of another, allowing the CPU to continue executing the second thread/process. A full context switch between processes also changes the page table base register, flushing the TLB (or using ASID tags to avoid flushing). See: Section 07 (Process Management); Section 09 (Scheduling)

copy-on-write (CoW) — A resource management optimization where copying a resource is deferred until a modification is made. After fork(), parent and child share the same physical pages; when either writes to a page, the kernel allocates a new physical page, copies the content, and updates the page table. Used in fork, filesystems (Btrfs, ZFS snapshots), and programming language runtimes. See: Section 07; Section 13 (Filesystems)

deadlock — A situation where two or more threads/processes are each waiting for a resource held by another, forming a cycle in the wait-for graph, and no thread can make progress. The four necessary conditions (Coffman conditions): mutual exclusion, hold-and-wait, no preemption, circular wait. Prevention requires breaking at least one condition. See: Section 10 (Synchronization)

epoch (RCU) — In Read-Copy-Update, a grace period is the time between when an old version of a data structure is replaced and when it is safe to free it: all readers that started before the replacement must have completed. The grace period detection mechanism tracks CPU-local quiescent states. See: Section 10 (Synchronization)

huge page — A page size larger than the base page size (4KB on x86-64); typically 2MB or 1GB on x86-64. Huge pages reduce TLB pressure by covering more memory per TLB entry. Transparent Huge Pages (THP) in Linux attempt to automatically back eligible memory regions with huge pages. Persistent and explicit huge pages are managed via /proc/sys/vm/nr_hugepages. See: Section 11 (Memory Management)

inode — The metadata structure describing a file in Unix filesystems, identified by an inode number. Contains: file type, permissions, owner, size, timestamps, and block pointers (direct, indirect, double-indirect) to the file's data. Does not contain the filename; the filename to inode mapping is stored in directory entries. Hard links create multiple directory entries pointing to the same inode. See: Section 13 (Filesystems)

jitter — Variation in the timing of a periodic event. In real-time systems, scheduling jitter is the deviation of actual task start time from its intended period. Sources: interrupt latency, scheduler overhead, cache effects, NUMA access time variation. See: Section 35 (Real-Time Systems)

kernel preemption — The ability of the kernel to interrupt an executing kernel thread at an arbitrary point to schedule another thread. Without preemption, a kernel thread holds the CPU until it voluntarily yields or returns to user space. With full preemption (PREEMPT_RT), spinlocks are replaced with sleeping locks and IRQ handlers can be preempted. See: Section 03 (Kernel Fundamentals); Section 35 (Real-Time Systems)

linearizability — The strongest consistency model for concurrent data structures: a concurrent execution is linearizable if every operation appears to take effect instantaneously at some point between its invocation and response. Operations are total-ordered at linearization points. Stronger than serializability (which allows the linearization point to be outside the operation's real-time interval). See: Section 10 (Synchronization); Section 17 (Distributed Systems)

MESI protocol — A cache coherence protocol with four states per cache line: Modified (dirty, exclusive), Exclusive (clean, exclusive), Shared (clean, possibly shared), Invalid. A write to a Shared or Invalid line requires broadcasting an Invalidate message to all caches holding that line. Variants: MOESI (adds Owned state), MESIF (adds Forward state for AMD). See: Section 06 (CPU Architecture)

memory consistency model — A specification of what values a load is allowed to return in the presence of concurrent stores. Sequential consistency (SC): all operations appear in a single global total order. Total Store Order (TSO): stores may be buffered before becoming visible, but stores from a single CPU are observed in order (x86). Relaxed: ARM and POWER allow extensive reordering; barriers required. See: Section 06 (CPU Architecture)

namespace (Linux) — A kernel mechanism that provides a process with an isolated view of a system resource. Types: PID (process ID space), mount (filesystem hierarchy), network (network interfaces, routing), IPC, UTS (hostname), user (UID/GID mapping), cgroup, time. Containers are built on top of namespaces. See: Section 20 (Containers)

NUMA (Non-Uniform Memory Access) — A multiprocessor memory architecture where the latency and bandwidth of memory access depends on the physical location of the memory relative to the accessing CPU. Local memory access (CPU accessing its own NUMA node's RAM) is faster than remote access (crossing the interconnect to another node's RAM). NUMA factor: ratio of remote to local latency, typically 1.5x-3x. See: Section 06 (CPU Architecture)

orphan process — A process whose parent has exited before it. The orphan is adopted by init (PID 1) or a subreaper. Contrasted with a zombie: a process that has exited but whose parent has not yet called wait(), so the kernel retains its process table entry and exit status. See: Section 07 (Process Management)

page fault — A CPU exception generated when the MMU cannot translate a virtual address, either because no mapping exists (segmentation fault / access violation) or because the page is present in the page table but not in physical memory (demand paging). The kernel's page fault handler either maps a new physical page, loads the page from swap, or sends SIGSEGV to the process. See: Section 11 (Memory Management)

quorum — In distributed consensus, the minimum number of nodes that must agree for a decision to be binding. For a cluster of N nodes tolerating F failures: majority quorum requires floor(N/2)+1 nodes. Any two quorums must overlap (pigeon hole), ensuring at least one node participates in both, preventing conflicting decisions. See: Section 17 (Distributed Systems)

RCU (Read-Copy-Update) — A synchronization mechanism optimized for read-heavy workloads. Readers proceed without locking. Writers create a new version of the data structure and atomically redirect pointers; the old version is freed after a grace period when no readers reference it. Fundamental to Linux kernel performance at SMP scale. See: Section 10 (Synchronization); Section 41 (Modern Kernel Challenges)

slab allocator — A kernel memory allocator that maintains per-object caches for frequently-allocated kernel objects (inodes, dentries, task structs). Each "slab" is one or more contiguous pages containing objects of the same type, pre-initialized and ready for use. Reduces fragmentation and initialization overhead. Linux implements SLAB, SLOB (simple, for embedded), and SLUB (simple, unqueued; the default). See: Section 11 (Memory Management)

spinlock — A lock implementation where the waiting thread continuously polls (spins on) the lock variable until it can acquire it, without sleeping. Appropriate for critical sections so short that sleeping and waking would take longer than spinning. Spinlocks are not preemptible in classic kernels; holding a spinlock with CONFIG_PREEMPT disabled prevents the CPU from being preempted. See: Section 10 (Synchronization)

system call — The mechanism by which a user-space process requests a service from the kernel. Involves a mode transition from user mode (ring 3) to kernel mode (ring 0), using the SYSCALL instruction (x86-64). The kernel validates arguments, performs the operation, and returns to user mode via SYSRET. See: Section 03 (Kernel Fundamentals)

TLB (Translation Lookaside Buffer) — A cache for virtual-to-physical page table translations, located in the MMU. A TLB hit translates a virtual address in 1-4 cycles; a TLB miss requires a page table walk (10-100+ cycles). TLB shootdown: broadcasting an IPI to all CPUs to invalidate their TLB entries for a given virtual address range, required when a mapping is removed. See: Section 11 (Memory Management)

write-ahead logging (WAL) — A crash recovery protocol requiring that log records describing a modification are flushed to durable storage before the modification itself is flushed. Ensures that modifications can be replayed or undone after a crash. The basis of ARIES, PostgreSQL, SQLite, and most production databases. See: Section 13 (Filesystems); Section 18 (Database Internals)

File Map

49-glossary/
├── 00-overview.md                    ← This file
├── 01-kernel-os-terms.md             (A-Z, ~80 terms)
├── 02-memory-management-terms.md     (~45 terms)
├── 03-storage-filesystem-terms.md    (~40 terms)
├── 04-networking-terms.md            (~55 terms)
├── 05-distributed-systems-terms.md   (~50 terms)
├── 06-database-terms.md              (~35 terms)
├── 07-security-terms.md              (~40 terms)
├── 08-performance-terms.md           (~35 terms)
├── 09-virtualization-container-terms.md (~30 terms)
├── 10-cloud-terms.md                 (~25 terms)
└── 11-hardware-architecture-terms.md (~30 terms)

Cross-References

Section 50 (Acronyms): acronym expansion for abbreviated forms of glossary terms
All Sections 00-48: each section uses terminology defined here
Section 45 (Learning Roadmaps): the glossary is recommended reference during all learning phases