NAND flash has an uncomfortable truth: blocks cannot be overwritten in place. When you update a file, the new data is written to fresh pages while the old pages become invalid ghosts—consuming physical space but no longer representing current data. Left unchecked, invalidity would eventually consume the entire SSD.

Garbage collection (GC) is the SSD firmware's continuous battle against this accumulation of obsolete data. By consolidating valid pages and erasing blocks full of invalid data, GC reclaims physical space and maintains the free block pool that enables continued writing. Yet GC is not free—it consumes flash bandwidth, increases wear, and can cause the dreaded performance cliff that brings even premium SSDs to their knees.

To understand why garbage collection is necessary, we must revisit the fundamental asymmetry of NAND flash:

Program Operation: Individual pages (4-16KB) can be written (programmed) independently.

Erase Operation: An entire block (64-512 pages, or 256KB-4MB) must be erased as a unit.

Write-Once Constraint: Pages can only transition from erased (all 1s) to programmed; any change requires erasing the entire block.

This asymmetry creates a dilemma: when you update 4KB of data, the SSD writes to a new page (the old page becomes invalid). You cannot overwrite the old page—it must wait for a block erase. But erasing the block destroys all 63-511 sibling pages, which may contain valid data.

The Accumulation Problem:

Consider a simple scenario:

1. Block A contains 64 pages of valid data
2. User overwrites 32 pages with new data
3. New data written to Block B (32 pages)
4. Block A now has 32 valid + 32 invalid pages
5. Process repeats: Block A valid count decreases, invalidity spreads

Event after event, invalid pages accumulate across blocks. The SSD appears full even when logical capacity is available because physical space is consumed by obsolete data.

Free Block Exhaustion:

When free blocks are depleted, writes cannot proceed. The SSD must:

1. Identify blocks with high invalidity
2. Copy remaining valid pages to a new block
3. Erase the victim block to create a free block
4. Resume host writes

This is foreground GC—blocking host operations until space is reclaimed.

Modern SSDs implement sophisticated garbage collection architectures designed to minimize host impact while maintaining free block availability.

GC Modes:

Idle Garbage Collection:

When the SSD detects no pending host commands, it executes GC in the background:

• Monitor host queues for incoming I/O
• Interruptible: immediately pause GC if host command arrives
• Maximally efficient: can use all flash channels for GC operations
• Proactive: maintain healthy free block pool before urgency develops

Idle GC is the ideal scenario—invisible to the host, completed during naturally occurring pauses in I/O activity.

Background Garbage Collection:

When free blocks drop below a soft threshold (e.g., 20% of over-provisioned space), background GC activates even during host activity:

• Interleave GC operations with host I/O
• Rate-limit GC to not overwhelm flash bandwidth
• Accept slightly elevated host latency to maintain free space
• Runs continuously until free blocks return to healthy levels

Foreground Garbage Collection:

If free blocks are exhausted before GC can reclaim space, foreground GC stalls host operations:

• Host writes blocked until GC completes
• Latency spikes to tens or hundreds of milliseconds
• Indicates either insufficient over-provisioning or overwhelming write rate
• Should be avoided through proper idle/background GC

Victim selection is the algorithm that chooses which blocks to garbage-collect. The objective: maximize reclaimed space while minimizing data movement (and thus write amplification).

Greedy Algorithm (Basic):

The simplest approach: always select the block with the most invalid pages.

Victim Selection:
1. For each block, count valid pages
2. Select block with minimum valid page count
3. GC that block: copy valid pages, erase block

Greedy Pros:

• Maximizes space reclaimed per GC operation
• Minimizes data movement (fewer valid pages to relocate)
• Simple to implement

Greedy Cons:

• May repeatedly select same blocks (wear concentration)
• Ignores data temperature (hot vs cold data mixing)
• Can increase long-term write amplification

Cost-Benefit Algorithm:

Analyzes the cost (valid data to relocate) versus benefit (space reclaimed and time until re-invalidation):

Cost-Benefit Score = (1 - u) × age / (2 × u)

Where:
- u = valid page ratio (valid_pages / total_pages)
- age = time since last data modification in block

Higher score = better victim candidate

Intuition:

• Low validity ratio (1-u high) → more space reclaimed per GC
• Higher age → data is cold; relocated data less likely to be invalidated soon
• Combining both: prefer blocks with old, mostly-invalid data

Cost-benefit reduces write amplification by avoiding blocks with recently-written data that will likely be invalidated anyway.

Write amplification factor (WAF) is the ratio of physical data written to flash versus logical data written by the host. It is the single most important metric for understanding SSD efficiency under write workloads.

WAF Calculation:

WAF = Physical Data Written to NAND / Logical Data Written by Host

Example:
- Host writes 100 GB of data
- SSD writes 300 GB to flash (including GC relocations)
- WAF = 300 / 100 = 3.0

Ideal vs Reality:

• WAF = 1.0: Perfect efficiency; every host write goes to flash exactly once
• WAF = 2-4: Typical for consumer SSDs under mixed workloads
• WAF = 5-10: High-write random workloads or nearly-full SSDs
• WAF = 20+: Pathological cases with severe GC pressure

WAF Impact:

1. Reduced Endurance: Every extra write consumes P/E cycles. WAF of 3 means you're consuming 3× the rated endurance.

2. Lower Sustained Performance: Flash bandwidth spent on GC is unavailable for host I/O. High WAF degrades throughput.

3. Increased Latency: GC operations add latency variability; high WAF means more frequent GC.

4. Power Consumption: Extra writes consume extra power—particularly impactful on mobile devices.

Minimizing Write Amplification:

• More over-provisioning: Higher OP means lower utilization, fewer GC operations
• Sequential writes: Sequential patterns avoid fragmentation; WAF approaches 1.0
• TRIM/Discard: Informing SSD of deleted data enables proactive cleanup
• Hot-cold separation: Keeping data types separate reduces valid page mixing
• Write batching: Larger writes reduce partial-page waste

Understanding garbage collection behavior is essential for predicting SSD performance under sustained workloads. The transition from cached to steady-state performance defines the practical experience of using an SSD.

Three Performance States:

The Steady-State Reality:

Most SSD benchmarks measure only burst performance—the first few gigabytes before caches fill and GC activates. Real-world sustained performance depends on:

1. SLC Cache Size: Larger cache delays transition but doesn't prevent it
2. Over-Provisioning: More OP provides GC headroom
3. NAND Speed: Faster base NAND improves steady-state floor
4. Controller Capability: Better algorithms minimize WAF and maximize parallelism
5. Workload Pattern: Random vs sequential dramatically affects GC pressure

Benchmarking Steady-State:

Professional SSD testing uses SNIA (Storage Networking Industry Association) protocols:

1. Pre-conditioning: Write entire drive 2×+ capacity with random data
2. Stabilization: Continue random writes until performance stabilizes (±10%)
3. Measurement: Record performance over extended period

This methodology reveals the true sustained performance—often 10-50× lower than peak specifications.

Latency During GC:

GC causes latency variability—the enemy of consistent performance:

• Normal read latency: 20-50μs
• Read during background GC: 50-200μs (flash channel contention)
• Read during foreground GC: 1-100ms (waiting for block erase)

For latency-sensitive applications (databases, real-time systems), QoS percentiles matter more than average latency. Look for:

• P99 latency (99th percentile)
• P99.9 latency (99.9th percentile)
• Maximum observed latency

An SSD with 30μs average but 50ms P99 will cause timeouts; one with 50μs average and 100μs P99 may be superior for your workload.

Modern SSD controllers implement sophisticated GC strategies beyond basic victim selection, aiming to minimize host impact while maintaining free space.

Multi-Stream Writes:

NVMe supports streams—a hint from the host indicating data temperature or lifecycle:

• Stream 1: Hot data (frequently updated)
• Stream 2: Warm data (occasionally updated)
• Stream 3: Cold data (rarely updated)

The SSD places each stream in separate blocks. Benefits:

• GC on hot blocks finds mostly-invalid pages
• GC on cold blocks happens rarely
• Reduced WAF from hot-cold mixing

Zoned Namespaces (ZNS):

ZNS represents a paradigm shift in SSD management:

• SSD exposes physical zone boundaries to host
• Host must write sequentially within each zone
• Host explicitly resets (erases) zones when done
• SSD performs zero or minimal garbage collection

By shifting GC responsibility to the host (which has application-level knowledge), ZNS achieves near-zero write amplification. Adoption is growing in cloud and hyperscale environments where the software stack can be modified.

Rate-Limited GC:

To prevent GC storms from overwhelming host I/O:

1. Allocate fixed bandwidth budget for GC per time window
2. Execute GC operations within budget
3. Pause GC when budget exhausted, resume next window
4. Adjust budget based on free block urgency

This provides predictable latency at the cost of potentially slower free space recovery.

Different workload patterns create dramatically different GC behaviors. Understanding these patterns helps predict and optimize SSD performance for specific use cases.

Sequential vs Random Writes:

Workload Size Impact:

• Small writes (4KB): Maximum page fragmentation; each 4KB write touches separate page; GC pressure high
• Large writes (128KB+): Fewer pages affected per logical unit; better block filling efficiency
• Aligned writes: Writes that align to page and block boundaries minimize partial-page overhead

SSD Capacity Utilization:

GC efficiency degrades non-linearly with utilization:

Enterprise recommendation: Keep SSDs below 80% utilization Consumer guidance: Avoid filling SSDs beyond 90%

We've explored the mechanics and implications of garbage collection—the essential process that reclaims flash space and enables continued SSD operation. Let's consolidate the key insights:

What's Next:

Garbage collection requires knowing which blocks contain invalid data. But SSDs cannot detect file deletion from host commands alone—when a file is deleted, the SSD remains unaware. The next page covers the TRIM command, which bridges this information gap by informing SSDs of deallocated blocks, enabling proactive cleanup and improved GC efficiency.