SSD Internals: Understanding Solid-State Storage

Every flash memory cell has a finite lifespan. Each program/erase cycle degrades the tunnel oxide, shifting threshold voltages and reducing the cell's ability to reliably store data. Without intervention, heavily-written blocks would fail while others remain pristine—creating premature SSD death with most capacity still viable.

Wear leveling is the algorithmic discipline that prevents this premature death. By intelligently distributing writes across all available blocks, wear leveling ensures that the entire flash array ages uniformly, maximizing the total write capacity the SSD can absorb before failure.

NAND flash cells degrade with each program/erase (P/E) cycle. The high voltages required to inject and remove electrons from the floating gate gradually damage the tunnel oxide layer, creating several degradation effects:

Physical Degradation Mechanisms:

1. Oxide Trap Generation: High-field stress creates electron trap sites in the oxide, causing threshold voltage shifts and widening voltage distributions.

2. Interface State Degradation: The silicon-oxide interface deteriorates, increasing subthreshold leakage and reducing sensing margins.

3. Charge Trapping Variation: Worn cells exhibit inconsistent charge trapping, leading to larger voltage variations between program cycles.

4. Retention Degradation: Damaged oxide leaks charge faster, reducing data retention time—especially problematic for long-term storage.

The Uneven Wear Problem:

Without wear leveling, I/O patterns create severe wear imbalances:

• Hot Data: Frequently updated files (logs, databases, temp files) continuously overwrite the same logical addresses. The underlying physical blocks receive disproportionate P/E cycles.

• Cold Data: Read-only content (OS files, applications, media) never changes. The physical blocks storing this data receive minimal wear.

• Result: Hot blocks fail after months while cold blocks retain 95%+ of their lifespan. The SSD fails when any blocks become unusable, wasting the longevity of untouched blocks.

Dynamic wear leveling is the simpler and more common technique, focusing on blocks that are actively being written. The core principle: when selecting a block for new writes, choose from the pool of free blocks with the lowest P/E counts.

How It Works:

1. The FTL maintains a free block pool—blocks that have been erased and are available for writing.

2. When new writes arrive, the controller selects a free block, prioritizing those with lower P/E counts.

3. After data is written and the source block's data is obsolete, the old block is erased and returned to the free pool.

4. Over time, all blocks in active circulation receive relatively even wear.

Implementation Details:

The controller tracks P/E counts for every block in a metadata structure:

Block Wear Table:
┌─────────┬──────────┬────────────┬───────────┐
│ Block # │ P/E Count│ Status     │ Last Erase│
├─────────┼──────────┼────────────┼───────────┤
│ 0       │ 1,247    │ IN_USE     │ 3 days    │
│ 1       │ 1,189    │ FREE       │ 1 day     │
│ 2       │ 1,302    │ IN_USE     │ 5 days    │
│ 3       │ 1,156    │ FREE       │ 2 days    │
│ ...     │ ...      │ ...        │ ...       │
└─────────┴──────────┴────────────┴───────────┘

When allocating, a min-heap or sorted structure efficiently identifies the lowest-wear free block in O(log n) time.

Static wear leveling (also called global wear leveling) addresses the cold data problem by actively relocating static data to distribute wear more evenly across the entire flash array—not just among actively-written blocks.

The Core Principle:

Periodically move cold data from low-wear blocks to high-wear blocks, freeing the low-wear blocks for new writes. This forces fresh blocks into active circulation.

Algorithm Overview:

1. Wear Disparity Detection: Monitor the difference between the highest and lowest P/E counts across all blocks.

2. Threshold Trigger: When disparity exceeds a threshold (e.g., 5-10% of rated endurance), initiate static wear leveling.

3. Cold Block Identification: Identify blocks with both low P/E counts AND old data (not recently written).

4. Data Migration: Copy cold data from low-wear block to high-wear block.

5. Block Swap: The low-wear block (now empty) enters the free pool for new writes; the high-wear block (now containing cold data) becomes inactive.

Write Amplification Cost:

Static wear leveling incurs write amplification—moving cold data that would otherwise remain untouched. This is a deliberate tradeoff:

• Cost: Each static WL operation requires reading a block (16-128 pages) and writing it elsewhere
• Benefit: The newly-freed block provides P/E cycles that would otherwise be locked away
• Net Effect: Typically positive for longevity, though aggressive static WL can accelerate overall wear

Well-tuned firmware balances the wear disparity threshold against the write amplification penalty.

Advanced Static WL Strategies:

1. Background Migration:

Perform static WL during idle periods (no pending host I/O) to avoid impacting performance. The controller maintains a queue of cold-block migration tasks executed opportunistically.

2. Incremental Balancing:

Instead of waiting for large disparity, continuously perform small migration tasks to maintain even wear. This prevents wear cliffs and smooths long-term degradation.

3. Workload-Aware Adaptation:

For predominantly read workloads (where cold data dominates), static WL is critical. For high-write workloads, dynamic WL may suffice. Advanced firmware adapts strategy to observed I/O patterns.

4. Hibernation Block Rotation:

In embedded systems with long powered-off periods, rotate which blocks store boot-critical data to prevent wear concentration.

Effective wear leveling requires accurate, persistent tracking of block-level wear statistics. The SSD must maintain this metadata across power cycles and provide visibility to both firmware and external monitoring systems.

Block-Level Counters:

Each physical block maintains several counters:

• P/E Count: Total program/erase cycles executed on this block
• Program Count: Number of times pages in this block were programmed (may exceed P/E count if pages are rewritten before block erase)
• Read Count: Total reads to detect and prevent read disturb
• Error Count: Cumulative bit errors detected during reads (trend indicates wear level)
• Last Access Timestamp: For cold data identification

Aggregating Block-Level Data:

While SSDs track per-block statistics internally, they typically expose aggregated metrics externally:

• Average P/E Count: Mean cycles across all blocks
• Maximum P/E Count: Highest wear on any single block
• Minimum P/E Count: Lowest wear (indicates static data)
• Wear Range: Max - Min (indicates wear leveling effectiveness)
• Percentage Life Remaining: Normalized estimate based on rated endurance

A well-worn SSD with effective wear leveling has a small wear range; a poorly-leveled drive shows large disparity.

Monitoring Wear Externally:

System administrators should regularly monitor SSD health:

# Linux: smartctl 
sudo smartctl -a /dev/nvme0n1

# Key attributes to watch:
# - Percentage Used Endurance Indicator
# - Available Spare
# - Media and Data Integrity Errors
# - Number of Error Information Log Entries

# NVMe-specific health log:
sudo nvme smart-log /dev/nvme0n1

# Windows: CrystalDiskInfo or manufacturer tools
# macOS: smartctl via Homebrew

Proactive replacement before 100% endurance consumption prevents data loss. Enterprise best practice: alert at 80% consumption, replace by 90%.

Over-provisioning (OP) is a critical enabler of wear leveling effectiveness. By hiding a portion of raw flash capacity from the host, SSDs maintain a pool of spare blocks that:

1. Provides free blocks for wear leveling to rotate through
2. Enables garbage collection without stalling host operations
3. Replaces blocks that fail during operation
4. Improves sustained write performance by reducing GC pressure

Calculating Over-Provisioning:

Consumer SSDs typically have 7-10% over-provisioning; enterprise drives may have 28% or more:

Over-Provisioning % = (Raw Capacity - User Capacity) / User Capacity × 100

Example (1TB Consumer SSD):
- Raw flash: 1,024 GB (actual NAND)
- User capacity: 953 GB (advertised)
- OP = (1024 - 953) / 953 × 100 = 7.4%

Example (960GB Enterprise SSD):
- Raw flash: 1,024 GB
- User capacity: 960 GB
- Additional reserved: 256 GB (not advertised)
- Effective OP = (1024 - 960 + 256) / 960 × 100 = 33%

How OP Enables Wear Leveling:

1. Larger Free Block Pool: More blocks available for rotation means more options for selecting low-wear blocks.

2. Lower Block Utilization: With more total blocks serving the same user capacity, each block absorbs fewer writes.

3. Reduced GC/WL Conflicts: Garbage collection and wear leveling compete for the same free blocks; more OP reduces contention.

4. Static WL Headroom: Extra blocks can absorb migrated cold data without displacing active data.

User-Configurable OP:

Some SSDs allow users to increase OP beyond factory settings:

• Create a partition smaller than full capacity
• Leave remaining space unpartitioned and unused
• TRIM the unused space to inform the SSD it's available

# Example: 1TB SSD configured for 850GB usable + 150GB extra OP
# Partition 850GB, leave remainder unallocated
# Issue TRIM to unallocated area:
blkdiscard --offset 850G --length 150G /dev/nvme0n1p1

This technique is particularly valuable for write-intensive workloads on consumer SSDs.

Wear leveling and garbage collection (GC) are deeply intertwined—both manage block allocation, both involve data migration, and both compete for free block resources. Modern SSD firmware integrates these functions to achieve both objectives efficiently.

Conflicting Objectives:

Garbage collection wants to:

• Consolidate valid data from partially-filled blocks
• Minimize data movement (reduce write amplification)
• Maximize free block availability

Wear leveling wants to:

• Distribute writes evenly across blocks
• Retire high-wear blocks from active duty
• Sometimes move data specifically to enable block rotation

These goals can conflict: GC might prefer to write to any available block quickly, while WL prefers a low-wear block.

Integrated Block Selection:

Advanced FTLs unify GC and WL block selection with a scoring function:

Block Score = w1 × (valid_page_count / total_pages)     // Lower = better GC candidate
            + w2 × (PE_count / max_PE_count)            // Lower = better WL candidate
            + w3 × (1 / data_age)                       // Older data = better WL candidate
            + w4 × error_rate_trend                     // Higher = prioritize migration

When selecting victim blocks for GC, the algorithm considers wear leveling factors. When free blocks are needed, the algorithm considers both availability and wear state.

Two-Phase Operation:

1. GC Phase: Select victim blocks with many invalid pages, relocate valid data to new blocks
2. WL Phase: During relocation, write to lowest-wear free blocks; track if cold data is being migrated to enable implicit static WL

This integrated approach achieves both objectives with single data movement operations.

Different flash cell types require different wear leveling strategies due to their varying endurance characteristics and performance profiles.

SLC: Minimal Concern

With 50,000-100,000 P/E cycle endurance, SLC flash can absorb tremendous write volumes. Simple dynamic wear leveling suffices for most workloads. Static wear leveling is rarely necessary except for extremely long-lived products (industrial controllers expected to operate 20+ years).

MLC: Balanced Approach

MLC's 3,000-10,000 cycle endurance requires attentive wear leveling:

• Dynamic WL essential for any write workload
• Static WL important for mixed read/write scenarios
• Over-provisioning of 15-28% recommended for enterprise

TLC: Critical Importance

With 500-3,000 cycle endurance, TLC drives depend heavily on wear leveling:

• Aggressive static WL to maximize block utilization
• Higher over-provisioning (20-30%) for write-intensive use
• Tighter wear disparity thresholds
• More frequent checkpoint of wear metadata

QLC: Survival Mode

QLC's extremely limited endurance (100-1,000 cycles) makes wear leveling a survival mechanism:

• Every write counts: WL must be maximally efficient
• SLC cache complication: Folding from SLC cache to QLC adds wear cycles
• Read-intensive bias: QLC is designed for predominantly read workloads; write leveling is critical for the writes that do occur
• Aggressive static WL: Even small imbalances waste significant endurance percentage
• High OP mandatory: 30-50% OP essential for any write activity

We've explored how wear leveling algorithms protect SSDs from premature death by distributing write wear evenly across all flash blocks. Let's consolidate the key insights:

What's Next:

Wear leveling creates invalid data (old versions of blocks after writes); garbage collection reclaims this space. The next page covers Garbage Collection—the algorithms that consolidate valid data, erase obsolete blocks, and maintain the free block pool that wear leveling depends upon.