20 min read
Storage Technologies & Architecture: HDD, NVMe, and Data Center Scale
Data persistence is the backbone of system design. This article analyzes the evolution of storage from mechanical actuators to quantum tunneling in NAND cells, culminating in the complex distributed architectures used in modern data centers, including Zoned Namespaces and DNA storage.
Storage devices (HDD, SSD)
HDDs (Hard Disk Drives) store data magnetically on spinning platters (5400-7200 RPM) using read/write heads, offering high capacity at low cost but with mechanical latency (seek times ~10ms). SSDs (Solid State Drives) use NAND flash memory with no moving parts, providing dramatically faster access (~0.1ms), higher durability, and lower power consumption, though at higher cost per gigabyte—NVMe SSDs connected via PCIe can achieve 7000+ MB/s speeds versus HDD's ~150 MB/s.
┌────────────────────────────────────────────────────────────────────┐ │ HDD vs SSD COMPARISON │ ├────────────────────────────────────────────────────────────────────┤ │ │ │ HDD (Hard Disk Drive) SSD (Solid State Drive) │ │ ┌─────────────────────┐ ┌─────────────────────┐ │ │ │ ◠◠◠◠◠◠◠◠◠◠◠ │ │ ┌───┬───┬───┬───┐ │ │ │ │ ◠ ╭─────────╮ ◠ │ │ │ N │ N │ N │ N │ │ │ │ │ ◠ │ Platter │ ◠ │ │ │ A │ A │ A │ A │ │ │ │ │ ◠ │ (magnetic│ ◠ │ │ │ N │ N │ N │ N │ │ │ │ │ ◠ │ disk) │ ◠ │ │ │ D │ D │ D │ D │ │ │ │ │ ◠ │ ⊙────┼──────┼──Head │ ├───┼───┼───┼───┤ │ │ │ │ ◠ ╰─────────╯ ◠ │ │ │ F │ F │ F │ F │ │ │ │ │ ◠◠◠◠◠◠◠◠◠◠◠ │ │ │ L │ L │ L │ L │ │ │ │ │ ↑ │ │ │ A │ A │ A │ A │ │ │ │ │ Spindle │ │ │ S │ S │ S │ S │ │ │ │ │ (5400-7200 │ │ │ H │ H │ H │ H │ │ │ │ │ RPM) │ │ └───┴───┴───┴───┘ │ │ │ └─────────────────────┘ └─────────────────────┘ │ │ │ ├────────────────────────────────────────────────────────────────────┤ │ │ │ COMPARISON: │ │ ┌────────────────┬──────────────────┬─────────────────────────┐ │ │ │ Feature │ HDD │ SSD (NVMe) │ │ │ ├────────────────┼──────────────────┼─────────────────────────┤ │ │ │ Read Speed │ ~150 MB/s │ ~7,000 MB/s │ │ │ │ Write Speed │ ~150 MB/s │ ~5,000 MB/s │ │ │ │ Latency │ ~10ms │ ~0.02ms │ │ │ │ Cost/TB │ ~$15 │ ~$50 │ │ │ │ Capacity │ Up to 24TB │ Up to 8TB (common) │ │ │ │ Power (idle) │ ~5W │ ~0.5W │ │ │ │ Durability │ Fragile (moving) │ Robust (no moving) │ │ │ │ Lifespan │ MTBF based │ TBW (writes limited) │ │ │ └────────────────┴──────────────────┴─────────────────────────┘ │ │ │ │ SSD INTERFACES: │ │ • SATA: 600 MB/s max (legacy) │ │ • NVMe PCIe 3.0: ~3,500 MB/s │ │ • NVMe PCIe 4.0: ~7,000 MB/s │ │ • NVMe PCIe 5.0: ~14,000 MB/s │ │ │ └────────────────────────────────────────────────────────────────────┘
// Storage performance comparison const storageDevices = { hdd7200: { type: 'HDD', readSpeed: 150, // MB/s writeSpeed: 150, latency: 10, // milliseconds costPerTB: 15, // USD iops: 100 // IO operations per second }, sataSSD: { type: 'SATA SSD', readSpeed: 550, writeSpeed: 520, latency: 0.1, costPerTB: 40, iops: 90000 }, nvmeSSD: { type: 'NVMe SSD', readSpeed: 7000, writeSpeed: 5000, latency: 0.02, costPerTB: 60, iops: 1000000 } }; // File copy time comparison function copyTime(fileSizeGB, device) { const sizeMB = fileSizeGB * 1024; const seconds = sizeMB / device.writeSpeed; return seconds.toFixed(1); } const gameSize = 100; // GB console.log('Time to copy 100GB game:'); console.log(`HDD: ${copyTime(gameSize, storageDevices.hdd7200)}s`); // 682.7s console.log(`NVMe: ${copyTime(gameSize, storageDevices.nvmeSSD)}s`); // 20.5s
Magnetic Storage Principles
Magnetic storage encodes data as magnetized regions on a ferromagnetic surface, with binary 0s and 1s represented by opposite magnetic polarities. Read/write heads use electromagnetic induction to detect or change these magnetic orientations—modern perpendicular recording aligns magnetic domains vertically, enabling higher density than older longitudinal recording.
Magnetic Recording Longitudinal Recording (older): Write head Magnetic Medium │ ┌──────────────────────────────────────┐ ▼ │ → → ← ← → → → ← ← ← → → │ ┌───────┐ │ N N S S N N N S S S N N │ │ N S │ └──────────────────────────────────────┘ └───────┘ Bits: 0 0 1 1 0 0 0 1 1 1 0 0 Horizontal magnetization ───► Perpendicular Recording (modern): Write head Magnetic Medium │ ┌──────────────────────────────────────┐ ▼ │ ↑ ↑ ↓ ↓ ↑ ↑ ↑ ↓ ↓ ↓ ↑ ↑ │ ┌───────┐ │ N N S S N N N S S S N N │ │ N │ │ S S N N S S S N N N S S │ │ S │ └──────────────────────────────────────┘ └───────┘ Bits: 0 0 1 1 0 0 0 1 1 1 0 0 │ Vertical magnetization allows smaller bit cells! Read Process: ┌─────────────────────────────────────────────────────────┐ │ Magnetized regions induce current in read head coil │ │ Transition = 1, No transition = 0 (simplified) │ └─────────────────────────────────────────────────────────┘
Hard Drive Architecture (Platters, Heads, Actuators)
A hard drive contains spinning aluminum or glass platters coated with magnetic material, with read/write heads floating nanometers above the surface on an air bearing. The actuator arm positions heads using a voice coil motor, accessing data organized in tracks (concentric circles) and sectors (track segments)—modern drives have multiple platters with heads on both sides.
Hard Drive Anatomy Top View: Side View: Spindle Motor Spindle │ │ ┌────┴────┐ ┌────┴────┐ ╱ ╲ ╱ ╲ │ Platter │── Head │ ╲ ╱ │ ├─────────┤── Head │ ╲ ╱ │ │ Platter │── Head │ ╲╱ │ ←Track ├─────────┤── Head │ ╱╲ │ │ Platter │── Head │ ╱ ╲ │ ├─────────┤── Head │ ╱ ╲ │ │ Platter │ ╲ ╱ ╲ ╱ └─────────┘ └───┬───┘ ▲ │ │ ┌───┴───┐ Voice Coil │ Head │ Actuator └───┬───┘ │ │ ┌─────────┴─────────┐ ┌────┴────┐ │ │ │Actuator │ │ ═══════════► │ │ Arm │ │ Arm moves heads │ └─────────┘ │ across platters │ └───────────────────┘ Data Organization: ┌─ Track (concentric circle) │ ┌─ Sector (512B or 4KB) │ │ ▼ ▼ ╭─────────────────────────╮ │ ╭─────────────────╮ │ │ │ ╭──────────╮ ││ │ │ │ │ ╭────╮ │││ ││ │ │ │ │ │ │ │││ ││ │ ← Cylinder: same track │ │ │ ╰────╯ │││ ││ │ on all platters │ │ ╰──────────╯ │││ │ │ ╰─────────────────╯│ │ ╰─────────────────────────╯ Access Time Components: Seek time: ~5-10ms (move head to track) Rotational latency: ~2-4ms (wait for sector, 7200 RPM) Transfer time: < 1ms
SSD Architecture (NAND Flash)
SSDs store data in NAND flash memory cells as trapped electrons in floating-gate transistors, organized into pages (~4-16KB), blocks (~128-512 pages), and dies. Unlike HDDs, SSDs have no moving parts, offering microsecond latency and high random I/O—but they require wear leveling and garbage collection because blocks must be erased before rewriting.
SSD Internal Architecture ┌─────────────────────────────────────────────────────────────┐ │ SSD Controller │ │ ┌──────────┐ ┌─────────────┐ ┌───────────┐ ┌───────────┐ │ │ │ Host │ │ FTL (Flash │ │ Wear │ │ Error │ │ │ │Interface │ │ Translation │ │ Leveling │ │ Correction│ │ │ │ (NVMe) │ │ Layer) │ │ │ │ (ECC) │ │ │ └──────────┘ └─────────────┘ └───────────┘ └───────────┘ │ └──────────────────────────┬──────────────────────────────────┘ │ ┌─────────┬───────────┼───────────┬─────────┐ ▼ ▼ ▼ ▼ ▼ ┌─────────┬─────────┬─────────┬─────────┬─────────┐ │ Channel │ Channel │ Channel │ Channel │ Channel │ │ 0 │ 1 │ 2 │ 3 │ 4 │ └────┬────┴────┬────┴────┬────┴────┬────┴────┬────┘ │ │ │ │ │ ┌────┴────┬────┴────┬────┴────┬────┴────┬────┴────┐ │ NAND │ NAND │ NAND │ NAND │ NAND │ │ Die │ Die │ Die │ Die │ Die │ └─────────┴─────────┴─────────┴─────────┴─────────┘ NAND Flash Hierarchy: ┌─────────────────────────────────────────────────────────────┐ │ Die │ │ ┌──────────────────────────────────────────────────────┐ │ │ │ Plane 0 │ │ │ │ ┌─────────────────────────────────────────────────┐ │ │ │ │ │ Block 0 │ │ │ │ │ │ ┌──────┬──────┬──────┬──────┬──────┬──────┐ │ │ │ │ │ │ │Page 0│Page 1│Page 2│ .... │Page N│ │ │ │ │ │ │ │ │ 4KB │ 4KB │ 4KB │ │ 4KB │ │ │ │ │ │ │ │ └──────┴──────┴──────┴──────┴──────┴──────┘ │ │ │ │ │ └─────────────────────────────────────────────────┘ │ │ │ │ Block 1, Block 2, ... Block N │ │ │ └──────────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────┘ Key Constraint: Erase-before-write ┌────────────────────────────────────────────────────────────┐ │ Read: Page-level (~50 μs) │ │ Write: Page-level (~500 μs) - only to erased pages │ │ Erase: Block-level (~3 ms) - erases ALL pages! │ └────────────────────────────────────────────────────────────┘
// SSD wear leveling simulation class SSDSimulator { constructor(blocks = 100, pagesPerBlock = 128) { this.blocks = Array.from({ length: blocks }, (_, i) => ({ id: i, eraseCount: 0, pages: new Array(pagesPerBlock).fill(null), valid: new Array(pagesPerBlock).fill(false) })); this.ftl = new Map(); // Logical -> Physical mapping this.pagesPerBlock = pagesPerBlock; } write(logicalAddr, data) { // Find block with lowest erase count (wear leveling) const block = this.blocks .filter(b => b.pages.some((p, i) => !b.valid[i])) .sort((a, b) => a.eraseCount - b.eraseCount)[0]; if (!block) { this.garbageCollect(); return this.write(logicalAddr, data); } // Find free page const pageIdx = block.pages.findIndex((p, i) => !block.valid[i]); // Invalidate old location if exists const oldPhys = this.ftl.get(logicalAddr); if (oldPhys) { const [oldBlock, oldPage] = oldPhys; this.blocks[oldBlock].valid[oldPage] = false; } // Write to new location block.pages[pageIdx] = data; block.valid[pageIdx] = true; this.ftl.set(logicalAddr, [block.id, pageIdx]); return { block: block.id, page: pageIdx }; } garbageCollect() { // Find block with most invalid pages const victim = this.blocks .map(b => ({ block: b, invalid: b.valid.filter(v => !v).length })) .sort((a, b) => b.invalid - a.invalid)[0].block; // Copy valid pages to new locations victim.pages.forEach((data, i) => { if (victim.valid[i] && data !== null) { // Find logical address and rewrite for (const [logical, [blockId, pageId]] of this.ftl) { if (blockId === victim.id && pageId === i) { // This triggers write to different block this.ftl.delete(logical); victim.valid[i] = false; break; } } } }); // Erase block victim.pages.fill(null); victim.valid.fill(false); victim.eraseCount++; console.log(`GC: Erased block ${victim.id}, erase count: ${victim.eraseCount}`); } }
SLC, MLC, TLC, QLC
These acronyms describe how many bits each NAND flash cell stores: SLC (1 bit) is fastest and most durable, MLC (2 bits) balances cost and performance, TLC (3 bits) offers good capacity at lower cost, and QLC (4 bits) maximizes density but has lowest endurance and speed. Each additional bit doubles capacity but exponentially increases complexity and reduces write cycles.
NAND Flash Cell Types Voltage Levels per Cell: SLC (1 bit) MLC (2 bits) TLC (3 bits) QLC (4 bits) 2 levels 4 levels 8 levels 16 levels ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ ─ "1" │ │ ─ "11" │ │ ─ "111" │ │ ─ "1111" │ │ │─────────│ ─ "10" │─────────│ │─────────│ │ │ │ │ │─────────│ │─────────│ │─────────│ │─────────│ ─ "01" │─────────│ │─────────│ │ │ │ │ │─────────│ │─────────│ │ │ │ │ │─────────│ ─ "000" │─────────│ │ │ ─ "0" │ │ ─ "00" │ │ │─────────│ └─────────┘ └─────────┘ └─────────┘ │ │ ─ "0000" └─────────┘ Voltage ↑ Comparison Table: ┌──────────┬───────┬────────┬─────────────┬─────────────┬──────────┐ │ Type │ Bits │ Levels │ Endurance │ Read Speed │ Cost/GB │ │ │/cell │ │ (P/E cycles)│ │ │ ├──────────┼───────┼────────┼─────────────┼─────────────┼──────────┤ │ SLC │ 1 │ 2 │ 100,000 │ Fastest │ $$$$ │ │ MLC │ 2 │ 4 │ 10,000 │ Fast │ $$$ │ │ TLC │ 3 │ 8 │ 3,000 │ Medium │ $$ │ │ QLC │ 4 │ 16 │ 1,000 │ Slower │ $ │ │ PLC(new) │ 5 │ 32 │ ~100 │ Slowest │ ¢ │ └──────────┴───────┴────────┴─────────────┴─────────────┴──────────┘ Why more bits = harder: - Voltage margins shrink (noise sensitivity) - Programming requires more precision - Read requires more voltage comparisons - Electron loss affects more bits
// Endurance calculation for different NAND types const nandTypes = { SLC: { bitsPerCell: 1, peCycles: 100000, readLatency: 25 }, MLC: { bitsPerCell: 2, peCycles: 10000, readLatency: 50 }, TLC: { bitsPerCell: 3, peCycles: 3000, readLatency: 75 }, QLC: { bitsPerCell: 4, peCycles: 1000, readLatency: 100 } }; function calculateSSDLifespan(type, capacityGB, dailyWritesGB) { const config = nandTypes[type]; const writeAmplification = 2; // Typical WA factor const overprovisioning = 0.07; // 7% OP const effectiveCapacity = capacityGB * (1 - overprovisioning); const totalTBW = (effectiveCapacity * config.peCycles) / writeAmplification / 1000; const yearsLifespan = totalTBW * 1000 / (dailyWritesGB * 365); return { type, totalTBW: totalTBW.toFixed(0), yearsAt50GBPerDay: yearsLifespan.toFixed(1) }; } // 1TB SSD with 50GB daily writes Object.keys(nandTypes).forEach(type => { console.log(calculateSSDLifespan(type, 1000, 50)); });
NVMe Protocol
NVMe (Non-Volatile Memory Express) is a protocol designed specifically for SSDs, replacing the legacy AHCI/SATA interface designed for spinning disks. It supports 65,535 queues with 65,536 commands each (vs SATA's 1 queue/32 commands), leverages PCIe's low latency, and reduces CPU overhead—enabling millions of IOPS and multi-GB/s throughput from modern SSDs.
NVMe vs SATA/AHCI Architecture SATA/AHCI (Legacy): NVMe (Modern): ┌─────────────┐ ┌─────────────┐ │ Application │ │ Application │ └──────┬──────┘ └──────┬──────┘ │ │ ┌──────▼──────┐ ┌──────▼──────┐ │ File System │ │ File System │ └──────┬──────┘ └──────┬──────┘ │ │ ┌──────▼──────┐ ┌──────▼──────┐ │ AHCI │ 1 queue │ NVMe │ 64K queues! │ Driver │ 32 commands │ Driver │ 64K cmds/queue └──────┬──────┘ └──────┬──────┘ │ │ ┌──────▼──────┐ ┌──────▼──────┐ │ SATA │ 6 Gbps │ PCIe │ 32+ Gbps │ Controller │ ~550 MB/s │ Direct │ 7+ GB/s └──────┬──────┘ └──────┬──────┘ │ │ ┌──────▼──────┐ ┌──────▼──────┐ │ SSD │ │ NVMe SSD │ └─────────────┘ └─────────────┘ NVMe Queue Structure: ┌─────────────────────────────────────────────────────────────┐ │ NVMe Controller │ │ │ │ ┌───────────────────────────────────────────────────────┐ │ │ │ Admin Queue (Queue 0) - config, management │ │ │ └───────────────────────────────────────────────────────┘ │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ I/O Q 1 │ │ I/O Q 2 │ │ I/O Q 3 │ ... │I/O Q 64K │ │ │ │ CPU 0 │ │ CPU 1 │ │ CPU 2 │ │ CPU N │ │ │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │ │ │ │ │ │ │ │ └────────────┴────────────┴────────────────┘ │ │ │ │ │ Parallel I/O │ └─────────────────────────────────────────────────────────────┘ Performance Comparison: ┌────────────────┬──────────────┬──────────────┐ │ Metric │ SATA SSD │ NVMe SSD │ ├────────────────┼──────────────┼──────────────┤ │ Sequential R │ 550 MB/s │ 7,000+ MB/s │ │ Sequential W │ 520 MB/s │ 5,000+ MB/s │ │ Random R IOPS │ 100K │ 1,000K+ │ │ Latency │ ~100 μs │ ~10 μs │ └────────────────┴──────────────┴──────────────┘
RAID Levels (0-6, 10, 50, 60)
RAID (Redundant Array of Independent Disks) combines multiple drives for performance, redundancy, or both. RAID 0 stripes data for speed (no redundancy), RAID 1 mirrors for safety, RAID 5 uses distributed parity (survives 1 drive failure), RAID 6 uses dual parity (survives 2), and nested levels like RAID 10 combine approaches for both performance and redundancy.
RAID Level Comparison RAID 0 (Striping): ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ │ A1 │ │ A2 │ │ A3 │ │ A4 │ Data split across drives │ B1 │ │ B2 │ │ B3 │ │ B4 │ ✓ Max performance │ C1 │ │ C2 │ │ C3 │ │ C4 │ ✗ No redundancy! └─────┘ └─────┘ └─────┘ └─────┘ Capacity: 100% RAID 1 (Mirroring): ┌─────┐ ┌─────┐ │ A │ │ A │ Exact copy │ B │ │ B │ ✓ Survives 1 failure │ C │ │ C │ ✗ 50% capacity └─────┘ └─────┘ Capacity: 50% RAID 5 (Striping + Distributed Parity): ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ │ A1 │ │ A2 │ │ A3 │ │ Ap │ Parity rotates │ B1 │ │ B2 │ │ Bp │ │ B3 │ ✓ Survives 1 failure │ C1 │ │ Cp │ │ C2 │ │ C3 │ Capacity: (N-1)/N │ Dp │ │ D1 │ │ D2 │ │ D3 │ Min 3 drives └─────┘ └─────┘ └─────┘ └─────┘ RAID 6 (Dual Parity): ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ │ A1 │ │ A2 │ │ Ap │ │ Aq │ Two parity blocks │ B1 │ │ Bp │ │ Bq │ │ B2 │ ✓ Survives 2 failures │ Cp │ │ Cq │ │ C1 │ │ C2 │ Capacity: (N-2)/N └─────┘ └─────┘ └─────┘ └─────┘ Min 4 drives RAID 10 (1+0, Mirrored Stripes): ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ │ A1 │ │ A1 │ │ A2 │ │ A2 │ Best of both │ B1 │ │ B1 │ │ B2 │ │ B2 │ ✓ High performance └──┬──┘ └──┬──┘ └──┬──┘ └──┬──┘ ✓ High redundancy └──────┘ └──────┘ Capacity: 50% Mirror Mirror └────────────┬────────────┘ Stripe Summary: ┌───────┬──────────┬───────────┬──────────┬─────────────┐ │ RAID │ Min Disks│ Capacity │ Failures │ Use Case │ ├───────┼──────────┼───────────┼──────────┼─────────────┤ │ 0 │ 2 │ 100% │ 0 │ Speed only │ │ 1 │ 2 │ 50% │ 1 │ Boot, OS │ │ 5 │ 3 │ (N-1)/N │ 1 │ General │ │ 6 │ 4 │ (N-2)/N │ 2 │ Critical │ │ 10 │ 4 │ 50% │ 1/mir │ Databases │ │ 50 │ 6 │ (N-1)/N │ 1/grp │ Large array │ │ 60 │ 8 │ (N-2)/N │ 2/grp │ Very large │ └───────┴──────────┴───────────┴──────────┴─────────────┘
// RAID capacity and performance calculator class RAIDCalculator { static calculate(level, driveCount, driveSize, driveSpeed) { const configs = { 0: { capacity: driveCount, readMultiplier: driveCount, failures: 0 }, 1: { capacity: 1, readMultiplier: 2, failures: driveCount - 1 }, 5: { capacity: driveCount - 1, readMultiplier: driveCount - 1, failures: 1 }, 6: { capacity: driveCount - 2, readMultiplier: driveCount - 2, failures: 2 }, 10: { capacity: driveCount / 2, readMultiplier: driveCount, failures: 1 } }; const config = configs[level]; if (!config) return null; return { level: `RAID ${level}`, usableCapacity: `${(config.capacity * driveSize).toFixed(0)} TB`, efficiency: `${(config.capacity / driveCount * 100).toFixed(0)}%`, theoreticalReadSpeed: `${(config.readMultiplier * driveSpeed).toFixed(0)} MB/s`, driveFailureTolerance: config.failures }; } } // Example: 8 x 4TB drives, each 250 MB/s const drives = { count: 8, size: 4, speed: 250 }; [0, 1, 5, 6, 10].forEach(level => { console.log(RAIDCalculator.calculate(level, drives.count, drives.size, drives.speed)); });
Storage Controllers
Storage controllers (HBAs, RAID controllers) are specialized processors that manage communication between the system and storage devices, handling protocol translation, caching, and RAID calculations. Hardware RAID controllers have dedicated processors and battery-backed cache for better performance and crash protection compared to software RAID, but add cost and potential failure points.
Storage Controller Types HBA (Host Bus Adapter) - Simple: ┌─────────────────────────────────────────┐ │ System │ │ ┌─────────────────────────────────┐ │ │ │ HBA Controller │ │ │ │ ┌─────────────────────────┐ │ │ │ │ │ Protocol Translation │ │ │ │ │ │ (PCIe ←→ SAS/SATA) │ │ │ │ │ └─────────────────────────┘ │ │ │ └──────────────┬──────────────────┘ │ └─────────────────┼──────────────────────┘ │ ┌────────────┼────────────┐ ▼ ▼ ▼ ┌─────┐ ┌─────┐ ┌─────┐ │Disk1│ │Disk2│ │Disk3│ └─────┘ └─────┘ └─────┘ OS sees individual disks (software RAID) Hardware RAID Controller - Full Featured: ┌─────────────────────────────────────────────────────────────┐ │ RAID Controller │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ Dedicated CPU │ │ │ │ (Offloads RAID calculations from main CPU) │ │ │ └─────────────────────────────────────────────────────┘ │ │ ┌────────────────┐ ┌─────────────────────────────────┐ │ │ │ Cache Memory │ │ Battery Backup Unit (BBU) │ │ │ │ 1-8 GB DDR │ │ Protects cache during power │ │ │ │ Write-back │ │ loss │ │ │ └────────────────┘ └─────────────────────────────────┘ │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ RAID Engine │ │ │ │ XOR/P+Q calculations, stripe management │ │ │ └─────────────────────────────────────────────────────┘ │ └────────────────────────┬────────────────────────────────────┘ │ ┌───────────────────┼───────────────────┐ ▼ ▼ ▼ ┌─────┐ ┌─────┐ ┌─────┐ │Disk1│ │Disk2│ │Disk3│ └─────┘ └─────┘ └─────┘ OS sees single virtual disk Controller Features: ┌────────────────────────────────────────────────────────┐ │ • Write-back cache (faster writes, BBU protected) │ │ • Background initialization │ │ • Hot spare management │ │ • Drive patrol read (proactive error detection) │ │ • Online capacity expansion │ │ • RAID level migration │ └────────────────────────────────────────────────────────┘
Optical Storage History (CD, DVD, Blu-ray)
Optical storage uses lasers to read (and sometimes write) data encoded as microscopic pits on reflective disc surfaces. CDs (1982, 700MB, 780nm infrared laser) evolved to DVDs (1995, 4.7-17GB, 650nm red laser) and Blu-ray (2006, 25-128GB, 405nm blue laser)—each generation used shorter wavelength lasers for smaller pits and higher density.
Optical Disc Evolution ┌─────────────────────────────────────────────────────────────┐ │ Laser Wavelength Comparison │ │ │ │ CD (780nm) DVD (650nm) Blu-ray (405nm) │ │ Infrared Red Blue-violet │ │ │ │ ████████ ██████ ████ │ │ Large pit Medium pit Small pit │ │ 1.6μm track 0.74μm track 0.32μm track │ └─────────────────────────────────────────────────────────────┘ Cross-Section of Disc: Laser beam │ ▼ ┌──────────────────────────────────────┐ │ Protective layer │ ├──────────────────────────────────────┤ │ Label side │ ├──────────────────────────────────────┤ │ Reflective layer (aluminum) │ ├──────────────────────────────────────┤ │ ▄▄ ▄▄▄▄ ▄▄ ▄▄▄▄▄▄ ▄▄ ▄▄ ▄▄ │ ← Pit pattern (data) │ Data layer (polycarbonate) │ ├──────────────────────────────────────┤ │ Clear substrate │ └──────────────────────────────────────┘ ▲ │ Laser reads from bottom Capacity Comparison: ┌─────────────┬───────────┬────────────┬───────────────────┐ │ Format │ Year │ Capacity │ Data Rate │ ├─────────────┼───────────┼────────────┼───────────────────┤ │ CD │ 1982 │ 700 MB │ 150 KB/s (1x) │ │ DVD-SL │ 1995 │ 4.7 GB │ 1.35 MB/s (1x) │ │ DVD-DL │ 1995 │ 8.5 GB │ 1.35 MB/s (1x) │ │ Blu-ray SL │ 2006 │ 25 GB │ 4.5 MB/s (1x) │ │ Blu-ray DL │ 2006 │ 50 GB │ 4.5 MB/s (1x) │ │ Blu-ray XL │ 2010 │ 100-128 GB │ 4.5 MB/s (1x) │ │ UHD BD │ 2015 │ 66-100 GB │ 12.5 MB/s │ └─────────────┴───────────┴────────────┴───────────────────┘
DNA Storage
Encoding digital data in synthetic DNA base sequences (A,T,G,C = 2 bits each), achieving theoretical density of 1 exabyte per cubic millimeter with millennia-scale durability; currently limited by slow, expensive synthesis ($1000s/MB) and sequencing read times (hours), suitable for cold archival storage.
Digital: 01001000 01101001 ("Hi") │ ▼ DNA: ATCG ATCG GCTA ATCG └─2 bits each─┘ │ ▼ ┌─────────────────────────┐ │ 🧬 Synthetic DNA Strand │ │ Density: 1 EB/mm³ │ │ Durability: 1000+ years│ │ Read: Hours (sequencing)│ │ Write: $$$ (synthesis) │ └─────────────────────────┘
Storage Area Networks (SAN)
A SAN is a dedicated high-speed network connecting storage arrays to servers, presenting block-level storage that appears as locally attached disks. SANs use specialized protocols (Fibre Channel, iSCSI) over redundant fabric topologies with multiple paths for high availability. Features include storage virtualization, thin provisioning, snapshots, and replication—essential for enterprise databases, virtualization, and mission-critical applications requiring shared storage.
┌─────────────────────────────────────────────────────────────────┐ │ STORAGE AREA NETWORK (SAN) │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ SAN ARCHITECTURE: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ Servers (Initiators) ││ │ │ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ││ │ │ │Server 1│ │Server 2│ │Server 3│ │Server 4│ ││ │ │ │ HBA │ │ HBA │ │ HBA │ │ HBA │ ││ │ │ └───┬────┘ └───┬────┘ └───┬────┘ └───┬────┘ ││ │ │ │ │ │ │ ││ │ │ ════╧═══════════╧═══════════╧═══════════╧════ ││ │ │ SAN Fabric A ││ │ │ ┌─────────────────────────────────────────────┐ ││ │ │ │ FC Switch A │ ││ │ │ │ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ │ ││ │ │ │ │P1│ │P2│ │P3│ │P4│ │P5│ │P6│ │P7│ │P8│ │ ││ │ │ │ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ │ ││ │ │ └──────────────────┬──────────────────────────┘ ││ │ │ │ ISL (Inter-Switch Link) ││ │ │ ┌──────────────────┴──────────────────────────┐ ││ │ │ │ FC Switch B │ ││ │ │ └──────────────────┬──────────────────────────┘ ││ │ │ ════════════════════╧═════════════════════════ ││ │ │ SAN Fabric B ││ │ │ │ ││ │ │ Storage Arrays (Targets) ││ │ │ ┌──────────────────┴──────────────────┐ ││ │ │ │ Storage Array │ ││ │ │ │ ┌─────────────────────────────────┐│ ││ │ │ │ │ Controllers (Active/Active) ││ ││ │ │ │ │ ┌─────────┐ ┌─────────┐ ││ ││ │ │ │ │ │ Ctrl A │◄──►│ Ctrl B │ ││ ││ │ │ │ │ │ FC │ │ FC │ ││ ││ │ │ │ │ └────┬────┘ └────┬────┘ ││ ││ │ │ │ └───────┼──────────────┼─────────┘│ ││ │ │ │ │ │ │ ││ │ │ │ ┌───────┴──────────────┴───────┐ │ ││ │ │ │ │ Disk Shelves │ │ ││ │ │ │ │ [D][D][D][D][D][D][D][D] │ │ ││ │ │ │ │ [D][D][D][D][D][D][D][D] │ │ ││ │ │ │ └──────────────────────────────┘ │ ││ │ │ └────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ KEY CONCEPTS: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ LUN (Logical Unit Number): ││ │ │ • Virtual disk carved from storage pool ││ │ │ • Presented to servers as block device ││ │ │ • Can span multiple physical disks (RAID) ││ │ │ ││ │ │ Zoning: ││ │ │ • Controls which initiators see which targets ││ │ │ • Implemented at switch level ││ │ │ • Types: Port zoning, WWN zoning ││ │ │ ││ │ │ LUN Masking: ││ │ │ • Controls which initiators can access which LUNs ││ │ │ • Implemented at storage array level ││ │ │ • Additional security layer beyond zoning ││ │ │ ││ │ │ Multipathing: ││ │ │ • Multiple physical paths to same LUN ││ │ │ • Provides redundancy and load balancing ││ │ │ • Software: PowerPath, dm-multipath ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ ZONING EXAMPLE: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ Zone 1: "Production_DB" ││ │ │ ┌────────────────────────────────────────────────────┐ ││ │ │ │ Members: │ ││ │ │ │ • Server1_HBA_WWN: 50:00:00:00:00:00:00:01 │ ││ │ │ │ • Server2_HBA_WWN: 50:00:00:00:00:00:00:02 │ ││ │ │ │ • Array_Port_WWN: 50:00:00:00:00:00:01:00 │ ││ │ │ └────────────────────────────────────────────────────┘ ││ │ │ ││ │ │ Zone 2: "Dev_Test" ││ │ │ ┌────────────────────────────────────────────────────┐ ││ │ │ │ Members: │ ││ │ │ │ • DevServer_HBA_WWN: 50:00:00:00:00:00:00:10 │ ││ │ │ │ • Array_Port_WWN: 50:00:00:00:00:00:02:00 │ ││ │ │ └────────────────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ └─────────────────────────────────────────────────────────────────┘
Fibre Channel
Fibre Channel (FC) is the dominant SAN protocol, providing lossless, low-latency block storage transport at speeds from 8/16/32/64 Gbps. FC uses a credit-based flow control mechanism preventing packet loss, with dedicated HBAs (Host Bus Adapters) in servers connecting to FC switches. The protocol stack includes FC-0 (physical), FC-1 (encoding), FC-2 (framing), and FC-4 (upper layer protocols like SCSI).
┌─────────────────────────────────────────────────────────────────┐ │ FIBRE CHANNEL ARCHITECTURE │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ FC PROTOCOL LAYERS: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ FC-4: Upper Layer Protocols │ ││ │ │ │ SCSI-FCP, FICON, FC-NVMe │ ││ │ │ ├─────────────────────────────────────────────────────┤ ││ │ │ │ FC-3: Common Services │ ││ │ │ │ Striping, Hunt groups, Multicast │ ││ │ │ ├─────────────────────────────────────────────────────┤ ││ │ │ │ FC-2: Framing and Flow Control │ ││ │ │ │ Frame format, Credit-based flow control │ ││ │ │ ├─────────────────────────────────────────────────────┤ ││ │ │ │ FC-1: Encode/Decode │ ││ │ │ │ 8b/10b (legacy), 64b/66b (modern) │ ││ │ │ ├─────────────────────────────────────────────────────┤ ││ │ │ │ FC-0: Physical │ ││ │ │ │ Optical/copper, connectors, cables │ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ FC SPEEDS EVOLUTION: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ Generation Speed Line Rate Effective BW ││ │ │ ────────────────────────────────────────────────────── ││ │ │ 1GFC 1 Gbps 1.0625 Gb 100 MB/s ││ │ │ 2GFC 2 Gbps 2.125 Gb 200 MB/s ││ │ │ 4GFC 4 Gbps 4.25 Gb 400 MB/s ││ │ │ 8GFC 8 Gbps 8.5 Gb 800 MB/s ││ │ │ 16GFC 16 Gbps 14.025 Gb 1600 MB/s ││ │ │ 32GFC 32 Gbps 28.05 Gb 3200 MB/s ││ │ │ 64GFC 64 Gbps 57.8 Gb 6400 MB/s ││ │ │ 128GFC 128 Gbps 112.2 Gb 12800 MB/s (emerging) ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ FC FRAME FORMAT: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ ┌────┬──────┬────────────────────────────────┬─────┬────┐ ││ │ │ │SOF │Frame │ Payload │ CRC │EOF │ ││ │ │ │ 4B │Header│ (0-2112 bytes) │ 4B │ 4B │ ││ │ │ │ │ 24B │ │ │ │ ││ │ │ └────┴──────┴────────────────────────────────┴─────┴────┘ ││ │ │ ││ │ │ Frame Header Fields: ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ R_CTL │ D_ID │ CS_CTL │ S_ID │ TYPE │ F_CTL │ │ ││ │ │ │ SEQ_ID│DF_CTL│ SEQ_CNT│ OX_ID│ RX_ID│ Parameter │ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ │ ││ │ │ • D_ID: Destination port address (24-bit) ││ │ │ • S_ID: Source port address (24-bit) ││ │ │ • OX_ID/RX_ID: Exchange identifiers for tracking ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ CREDIT-BASED FLOW CONTROL: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ Initiator Target ││ │ │ ┌─────────┐ ┌─────────┐ ││ │ │ │ Buffer │ │ Buffer │ ││ │ │ │ Credits │ │ Credits │ ││ │ │ │ = 8 │ │ = 8 │ ││ │ │ └────┬────┘ └────┬────┘ ││ │ │ │ │ ││ │ │ │──── Frame 1 ────────────────────►│ Credit: 7 ││ │ │ │──── Frame 2 ────────────────────►│ Credit: 6 ││ │ │ │──── Frame 3 ────────────────────►│ Credit: 5 ││ │ │ │ │ ││ │ │ │◄─── R_RDY (credit replenish) ─────│ Credit: 6 ││ │ │ │◄─── R_RDY ────────────────────────│ Credit: 7 ││ │ │ │ │ ││ │ │ ││ │ │ • No frames lost (unlike TCP/IP) ││ │ │ • Sender stops when credits exhausted ││ │ │ • Receiver returns credits when buffer freed ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ FC TOPOLOGIES: │ │ │ │ Point-to-Point: Arbitrated Loop: Switched Fabric: │ │ ┌───┐ ┌───┐ ┌───┐ ┌───────────────┐ │ │ │HBA│────│Tgt│ │ │◄──┐ │ FC Switch │ │ │ └───┘ └───┘ │ N │ │ │ ┌──┐ ┌──┐ │ │ │ │ _ │ │ │ │P1│ │P2│... │ │ │ (Direct connect) │ L │ │ │ └──┘ └──┘ │ │ │ │ │ │ └───────┬───────┘ │ │ └───┘───┘ ┌──────┴──────┐ │ │ (Legacy, rare) │ All devices │ │ │ │ can talk │ │ │ └─────────────┘ │ └─────────────────────────────────────────────────────────────────┘
iSCSI Hardware
iSCSI (Internet SCSI) encapsulates SCSI commands over TCP/IP, enabling block storage over standard Ethernet infrastructure. While software initiators use regular NICs, hardware iSCSI uses TOE (TCP Offload Engine) cards or iSCSI HBAs that offload protocol processing from the CPU. iSCSI is cost-effective for smaller deployments but requires careful network design with jumbo frames, dedicated VLANs, and QoS to achieve performance approaching native FC.
┌─────────────────────────────────────────────────────────────────┐ │ iSCSI ARCHITECTURE │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ iSCSI PROTOCOL STACK: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ SCSI Command Set │ ││ │ │ ├─────────────────────────────────────────────────────┤ ││ │ │ │ iSCSI Protocol (RFC 7143) │ ││ │ │ │ • Login, Session management │ ││ │ │ │ • PDU framing, Error recovery │ ││ │ │ ├─────────────────────────────────────────────────────┤ ││ │ │ │ TCP (Reliable transport) │ ││ │ │ ├─────────────────────────────────────────────────────┤ ││ │ │ │ IP (Network layer) │ ││ │ │ ├─────────────────────────────────────────────────────┤ ││ │ │ │ Ethernet (Data link) │ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ iSCSI IMPLEMENTATION OPTIONS: │ │ │ │ Software Initiator: Hardware Initiator (HBA): │ │ ┌─────────────────────┐ ┌─────────────────────┐ │ │ │ ┌─────────────────┐ │ │ ┌─────────────────┐ │ │ │ │ │ Application │ │ │ │ Application │ │ │ │ │ ├─────────────────┤ │ │ ├─────────────────┤ │ │ │ │ │ iSCSI Driver │ │ │ │ iSCSI Driver │ │ │ │ │ ├─────────────────┤ │ │ └────────┬────────┘ │ │ │ │ │ TCP/IP Stack │ │ │ │ │ │ │ │ ├─────────────────┤ │ │ ┌────────┴────────
│ │ │ NIC Driver │ │ │ │ iSCSI HBA │ │ │ │ │ └────────┬────────┘ │ │ │ ┌────────────┐ │ │ │ │ │ │ │ │ │ │TCP Offload │ │ │ │ │ │ ┌────────┴────────┐ │ │ │ │iSCSI Engine│ │ │ │ │ │ │ Standard NIC │ │ │ │ └────────────┘ │ │ │ │ │ │ (CPU does │ │ │ └────────┬────────┘ │ │ │ │ │ all work) │ │ │ │ │ │ │ │ └─────────────────┘ │ │ (Dedicated HW) │ │ │ └─────────────────────┘ └─────────────────────┘ │ │ │ │ CPU Load: High (30-40%) CPU Load: Low (<5%) │ │ Cost: $0 (software) Cost: $500-2000 │ │ Latency: Higher Latency: Lower │ │ │ │ iSCSI NETWORK DESIGN: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ Servers Storage ││ │ │ ┌────────┐ ┌────────────┐ ││ │ │ │Server 1│ │ iSCSI │ ││ │ │ │ NIC A │──┐ ┌────│ Target │ ││ │ │ │ NIC B │──┼────┐ │ │ Array │ ││ │ │ └────────┘ │ │ │ └────────────┘ ││ │ │ │ │ │ ││ │ │ ┌────────┐ │ │ │ Best Practices: ││ │ │ │Server 2│ │ │ │ • Dedicated iSCSI VLAN ││ │ │ │ NIC A │──┤ │ │ • Jumbo frames (MTU 9000) ││ │ │ │ NIC B │──┼────┤ │ • Flow control enabled ││ │ │ └────────┘ │ │ │ • Multipath (MPIO) ││ │ │ │ │ │ • Separate from LAN traffic ││ │ │ ┌────┴────┴┐ ┌─┴────┴─┐ ││ │ │ │ Switch A │ │Switch B│ (Redundant fabric) ││ │ │ │ VLAN 100 │ │VLAN 100│ ││ │ │ └──────────┘ └────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ iSCSI NAMING (IQN): │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ Format: iqn.yyyy-mm.reverse-domain:unique-name ││ │ │ ││ │ │ Examples: ││ │ │ • iqn.2024-01.com.example:storage.lun0 ││ │ │ • iqn.2024-01.com.example:server1.initiator ││ │ │ ││ │ │ Discovery Methods: ││ │ │ • SendTargets: Query target portal for available LUNs ││ │ │ • iSNS: Internet Storage Name Service (like DNS for iSCSI) ││ │ │ • Static: Manually configure target addresses ││ │ └─────────────────────────────────────────────────────────────┘│ └─────────────────────────────────────────────────────────────────┘
```javascript
// iSCSI target discovery simulation
class iSCSIInitiator {
constructor(iqn) {
this.iqn = iqn;
this.sessions = new Map();
this.discoveredTargets = [];
}
// SendTargets discovery
async discoverTargets(portalIP, portalPort = 3260) {
console.log(`Discovering targets at ${portalIP}:${portalPort}`);
// Simulated discovery response
this.discoveredTargets = [
{
iqn: 'iqn.2024-01.com.storage:disk1',
portal: `${portalIP}:${portalPort}`,
luns: [0, 1, 2]
},
{
iqn: 'iqn.2024-01.com.storage:disk2',
portal: `${portalIP}:${portalPort}`,
luns: [0]
}
];
return this.discoveredTargets;
}
// Login to target
async login(targetIQN, options = {}) {
const target = this.discoveredTargets.find(t => t.iqn === targetIQN);
if (!target) throw new Error('Target not found');
const session = {
tsih: Math.floor(Math.random() * 65535), // Target Session ID
isid: this.generateISID(),
connections: [{
cid: 1,
state: 'LOGGED_IN',
portal: target.portal
}],
params: {
maxRecvDataSegmentLength: options.maxRecv || 262144,
maxBurstLength: options.maxBurst || 262144,
firstBurstLength: options.firstBurst || 65536,
immediateData: true,
initialR2T: false
}
};
this.sessions.set(targetIQN, session);
console.log(`Logged into ${targetIQN}, TSIH: ${session.tsih}`);
return session;
}
generateISID() {
// Initiator Session ID (6 bytes)
return Buffer.from([0x00, 0x02, 0x3d,
Math.random() * 255, Math.random() * 255, Math.random() * 255]);
}
// SCSI command over iSCSI
async scsiCommand(targetIQN, lun, cdb, dataOut = null) {
const session = this.sessions.get(targetIQN);
if (!session) throw new Error('Not logged in');
// Build iSCSI PDU
const pdu = {
opcode: 0x01, // SCSI Command
flags: 0x81, // Final, Read
totalAHSLength: 0,
dataSegmentLength: dataOut ? dataOut.length : 0,
lun: lun,
initiatorTaskTag: Math.floor(Math.random() * 0xFFFFFFFF),
expectedDataTransferLength: 512, // For read
cdb: cdb
};
console.log(`Sending SCSI command to LUN ${lun}:`,
Buffer.from(cdb).toString('hex'));
// Simulated response
return {
status: 0x00, // GOOD
data: Buffer.alloc(512).fill(0xAA)
};
}
}
// Usage
const initiator = new iSCSIInitiator('iqn.2024-01.com.server:host1');
// await initiator.discoverTargets('192.168.1.100');
// await initiator.login('iqn.2024-01.com.storage:disk1');
// await initiator.scsiCommand('iqn.2024-01.com.storage:disk1', 0,
// [0x28, 0, 0, 0, 0, 0, 0, 0, 1, 0]); // READ(10)
NVMe-oF (NVMe over Fabrics)
NVMe-oF extends the NVMe protocol beyond local PCIe to network fabrics, delivering sub-10μs latency compared to 100μs+ for iSCSI. Transport options include RDMA (RoCE, InfiniBand), Fibre Channel (FC-NVMe), and TCP. NVMe-oF maintains NVMe's parallelism with thousands of queues and millions of commands outstanding, enabling disaggregated storage architectures where remote NVMe SSDs perform nearly as well as local drives.
┌─────────────────────────────────────────────────────────────────┐ │ NVMe OVER FABRICS (NVMe-oF) │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ NVMe-oF ARCHITECTURE: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ Host (Initiator) Target (Storage) ││ │ │ ┌─────────────────┐ ┌─────────────────┐ ││ │ │ │ Application │ │ NVMe SSDs │ ││ │ │ ├─────────────────┤ │ ┌───┐┌───┐┌───┐│ ││ │ │ │ NVMe Driver │ │ │SSD││SSD││SSD││ ││ │ │ ├─────────────────┤ │ └───┘└───┘└───┘│ ││ │ │ │ NVMe-oF Host │ ├─────────────────┤ ││ │ │ │ Driver │ │ NVMe-oF Target │ ││ │ │ ├─────────────────┤ │ Controller │ ││ │ │ │ Transport │◄─────────►│ Transport │ ││ │ │ │ (RDMA/TCP/FC) │ Fabric │ (RDMA/TCP/FC) │ ││ │ │ └─────────────────┘ └─────────────────┘ ││ │ │ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ TRANSPORT OPTIONS: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ ┌─────────────┬─────────────┬─────────────┬─────────────┐ ││ │ │ │ NVMe/RDMA │ NVMe/TCP │ NVMe/FC │ NVMe/PCIe │ ││ │ │ │ (RoCEv2) │ │ (FC-NVMe) │ (Local) │ ││ │ │ ├─────────────┼─────────────┼─────────────┼─────────────┤ ││ │ │ │ Latency: │ Latency: │ Latency: │ Latency: │ ││ │ │ │ ~5-10 μs │ ~30-50 μs │ ~10-20 μs │ ~2-5 μs │ ││ │ │ ├─────────────┼─────────────┼─────────────┼─────────────┤ ││ │ │ │ Requires: │ Requires: │ Requires: │ Requires: │ ││ │ │ │ RDMA NIC │ Standard NIC│ FC HBA │ Direct conn │ ││ │ │ │ Lossless net│ (any) │ FC switches │ │ ││ │ │ ├─────────────┼─────────────┼─────────────┼─────────────┤ ││ │ │ │ Best for: │ Best for: │ Best for: │ Best for: │ ││ │ │ │ Lowest lat │ Broad compat│ Existing FC │ Single host │ ││ │ │ │ HPC, AI │ Enterprise │ infra │ │ ││ │ │ └─────────────┴─────────────┴─────────────┴─────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ LATENCY COMPARISON: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ Protocol Latency (4K Random Read) ││ │ │ ───────────────────────────────────────── ││ │ │ Local NVMe ████░░░░░░░░░░░░░░░░░░░░░░░░ ~10 μs ││ │ │ NVMe/RDMA ██████░░░░░░░░░░░░░░░░░░░░░░ ~15 μs ││ │ │ NVMe/FC ████████░░░░░░░░░░░░░░░░░░░░ ~25 μs ││ │ │ NVMe/TCP ██████████████░░░░░░░░░░░░░░ ~50 μs ││ │ │ iSCSI ██████████████████████░░░░░░ ~100 μs ││ │ │ FC-SCSI ████████████████████░░░░░░░░ ~80 μs ││ │ │ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ NVMe-oF QUEUE MODEL: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ Host Target ││ │ │ ┌───────────────────┐ ┌───────────────────┐ ││ │ │ │ Admin Queue │◄───────────►│ Admin Queue │ ││ │ │ │ (Discovery, Mgmt) │ │ │ ││ │ │ ├───────────────────┤ ├───────────────────┤ ││ │ │ │ I/O Queue 1 │◄───────────►│ I/O Queue 1 │ ││ │ │ │ (64K cmds deep) │ │ │ ││ │ │ ├───────────────────┤ ├───────────────────┤ ││ │ │ │ I/O Queue 2 │◄───────────►│ I/O Queue 2 │ ││ │ │ ├───────────────────┤ ├───────────────────┤ ││ │ │ │ ... │ │ ... │ ││ │ │ ├───────────────────┤ ├───────────────────┤ ││ │ │ │ I/O Queue N │◄───────────►│ I/O Queue N │ ││ │ │ │ (up to 65535) │ │ │ ││ │ │ └───────────────────┘ └───────────────────┘ ││ │ │ ││ │ │ • Each CPU core can have dedicated queue pair ││ │ │ • No locking, no contention ││ │ │ • Millions of IOPS possible ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ NVMe-oF DISCOVERY: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ 1. Host connects to Discovery Controller ││ │ │ (well-known NQN: nqn.2014-08.org.nvmexpress.discovery) ││ │ │ ││ │ │ 2. Discovery Controller returns list of subsystems: ││ │ │ ┌────────────────────────────────────────────────┐ ││ │ │ │ NQN: nqn.2024-01.com.vendor:subsys1 │ ││ │ │ │ Transport: RDMA │ ││ │ │ │ Address: 192.168.1.100:4420 │ ││ │ │ ├────────────────────────────────────────────────┤ ││ │ │ │ NQN: nqn.2024-01.com.vendor:subsys2 │ ││ │ │ │ Transport: TCP │ ││ │ │ │ Address: 192.168.1.101:4420 │ ││ │ │ └────────────────────────────────────────────────┘ ││ │ │ ││ │ │ 3. Host connects to desired subsystem ││ │ │ ││ │ └─────────────────────────────────────────────────────────────┘│ └─────────────────────────────────────────────────────────────────┘
Storage Class Memory (Intel Optane)
Storage Class Memory (SCM) bridges the gap between DRAM and NAND flash, offering byte-addressable persistent memory with near-DRAM latency. Intel Optane (3D XPoint technology) provided ~10μs latency vs ~100μs for NVMe SSDs, with higher endurance (1000x NAND). Used in Memory Mode (volatile DRAM extension) or App Direct Mode (persistent storage), though Intel discontinued Optane in 2022, CXL-attached memory is emerging as successor.
┌─────────────────────────────────────────────────────────────────┐ │ STORAGE CLASS MEMORY │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ MEMORY/STORAGE HIERARCHY: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ Speed ││ │ │ │ ││ │ │ │ ┌─────────┐ ││ │ │ │ │CPU Cache│ ~1-10 ns ││ │ │ │ └────┬────┘ ││ │ │ │ │ ││ │ │ │ ┌────┴────┐ ││ │ │ │ │ DRAM │ ~50-100 ns ││ │ │ │ └────┬────┘ ││ │ │ │ │ ││ │ │ │ ┌────┴────┐ ◄── Storage Class Memory (SCM) ││ │ │ │ │ Optane │ ~300-500 ns (10x slower than DRAM) ││ │ │ │ │ PMem │ (But 1000x faster than NAND) ││ │ │ │ └────┬────┘ ││ │ │ │ │ ││ │ │ │ ┌────┴────┐ ││ │ │ │ │NVMe SSD │ ~10,000-100,000 ns (10-100 μs) ││ │ │ │ └────┬────┘ ││ │ │ │ │ ││ │ │ │ ┌────┴────┐ ││ │ │ ▼ │ HDD │ ~5,000,000-10,000,000 ns (5-10 ms) ││ │ │ └─────────┘ ││ │ │ ││ │ │ Capacity ──────────────────────────────────────────────► ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ INTEL OPTANE PERSISTENT MEMORY MODES: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ MEMORY MODE (Volatile): ││ │ │ ┌───────────────────────────────────────────────────────┐ ││ │ │ │ │ ││ │ │ │ Application sees: Large DRAM pool │ ││ │ │ │ │ ││ │ │ │ ┌─────────────────────────────────────────────────┐ │ ││ │ │ │ │ Virtual Memory │ │ ││ │ │ │ └─────────────────────────────────────────────────┘ │ ││ │ │ │ │ │ ││ │ │ │ ┌─────────────────────┴─────────────────────┐ │ ││ │ │ │ │ DRAM (Cache) │ Optane PMem │ │ ││ │ │ │ │ 256 GB │ 1.5 TB │ │ ││ │ │ │ │ (Fast tier) │ (Capacity tier) │ │ ││ │ │ │ └──────────────────┴────────────────────────┘ │ ││ │ │ │ │ ││ │ │ │ • DRAM acts as cache for PMem │ ││ │ │ │ • No application changes needed │ ││ │ │ │ • Data NOT persistent (lost on reboot) │ ││ │ │ └───────────────────────────────────────────────────────┘ ││ │ │ ││ │ │ APP DIRECT MODE (Persistent): ││ │ │ ┌───────────────────────────────────────────────────────┐ ││ │ │ │ │ ││ │ │ │ Application sees: Separate DRAM + PMem │ ││ │ │ │ │ ││ │ │ │ ┌──────────────┐ ┌──────────────────────────┐ │ ││ │ │ │ │ DRAM │ │ Optane PMem │ │ ││ │ │ │ │ 256 GB │ │ 1.5 TB │ │ ││ │ │ │ │ (Volatile) │ │ (Persistent!) │ │ ││ │ │ │ └──────────────┘ └──────────────────────────┘ │ ││ │ │ │ │ │ ││ │ │ │ ┌────────┴────────┐ │ ││ │ │ │ │ │ │ ││ │ │ │ ┌─────┴─────┐ ┌──────┴─────┐ │ ││ │ │ │ │ DAX FS │ │ Block │ │ ││ │ │ │ │ (ext4-dax)│ │ Device │ │ ││ │ │ │ │ │ │ (/dev/pmem)│ │ ││ │ │ │ └───────────┘ └────────────┘ │ ││ │ │ │ │ ││ │ │ │ • Direct byte-addressable access │ ││ │ │ │ • Survives reboot │ ││ │ │ │ • Requires PMem-aware applications │ ││ │ │ └───────────────────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ 3D XPOINT TECHNOLOGY: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ Structure (crosspoint array): ││ │ │ ││ │ │ Word Lines ││ │ │ │ │ │ │ ││ │ │ ──────┼─┼─┼─┼──── Bit Lines ││ │ │ │●│●│●│ ● = Memory cell ││ │ │ ──────┼─┼─┼─┼──── (selector + PCM) ││ │ │ │●│●│●│ ││ │ │ ──────┼─┼─┼─┼──── ││ │ │ │●│●│●│ ││ │ │ ││ │ │ • No transistor per cell (higher density) ││ │ │ • Phase-change material stores data ││ │ │ • Bit-alterable (vs page-based NAND) ││ │ │ • 1000x endurance vs NAND ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ OPTANE SPECIFICATIONS: │ │ ┌─────────────────┬───────────────────────────────────────┐ │ │ │ Capacity │ 128GB, 256GB, 512GB per DIMM │ │ │ │ Interface │ DDR-T (DDR4 physical, PMem protocol) │ │ │ │ Read Latency │ ~300 ns (vs ~80 ns DRAM) │ │ │ │ Write Latency │ ~100 ns │ │ │ │ Read BW │ ~6.8 GB/s per DIMM │ │ │ │ Write BW │ ~2.3 GB/s per DIMM │ │ │ │ Endurance │ ~365 PBW (Petabytes Written) │ │ │ └─────────────────┴───────────────────────────────────────┘ │ │ │ │ SUCCESSOR: CXL-attached Memory │ │ • CXL.mem protocol for memory expansion │ │ • Similar use cases, industry-standard interface │ │ • Multiple vendors (Samsung, SK Hynix, Micron) │ └─────────────────────────────────────────────────────────────────┘
Computational Storage
Computational storage integrates processing capabilities directly into storage devices, enabling data processing at the source rather than moving data to host CPUs. This reduces data movement (the biggest bottleneck), improves latency, and offloads host resources. Applications include transparent compression/encryption, database query acceleration, video transcoding, and AI inference—emerging standards from SNIA define programming interfaces for computational storage devices (CSDs).
┌─────────────────────────────────────────────────────────────────┐ │ COMPUTATIONAL STORAGE │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ TRADITIONAL vs COMPUTATIONAL STORAGE: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ Traditional (Data Movement): ││ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ││ │ │ │ Storage │ ──────► │ Host │ ──────► │ Result │ ││ │ │ │ (1 TB) │ Read │ CPU │ Process │ │ ││ │ │ └──────────┘ 1 TB └──────────┘ └──────────┘ ││ │ │ ││ │ │ Computational Storage (Process in Place): ││ │ │ ┌──────────────────────────────┐ ┌──────────┐ ││ │ │ │ Storage + Compute │ ──────► │ Result │ ││ │ │ │ ┌────────┐ ┌──────────┐ │ Only │ (1 KB) │ ││ │ │ │ │ SSD │───►│ Compute │ │ results │ │ ││ │ │ │ │ (1 TB) │ │ Engine │ │ └──────────┘ ││ │ │ │ └────────┘ └──────────┘ │ ││ │ │ └──────────────────────────────┘ ││ │ │ ││ │ │ Benefit: 1000x less data movement! ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ COMPUTATIONAL STORAGE ARCHITECTURE: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ Computational Storage Device (CSD) │ ││ │ │ │ │ ││ │ │ │ ┌─────────────────────────────────────────────────┐ │ ││ │ │ │ │ Host Interface (PCIe/NVMe) │ │ ││ │ │ │ └─────────────────────┬───────────────────────────┘ │ ││ │ │ │ │ │ ││ │ │ │ ┌─────────────────────┴───────────────────────────┐ │ ││ │ │ │ │ NVMe Controller │ │ ││ │ │ │ │ ┌──────────────┐ ┌──────────────────────┐ │ │ ││ │ │ │ │ │ Standard I/O │ │ Computational Engine │ │ │ ││ │ │ │ │ │ Commands │ │ ┌────────────────┐ │ │ │ ││ │ │ │ │ └──────────────┘ │ │ ARM Cores / │ │ │ │ ││ │ │ │ │ │ │ FPGA / ASIC │ │ │ │ ││ │ │ │ │ │ └────────────────┘ │ │ │ ││ │ │ │ │ │ ┌────────────────┐ │ │ │ ││ │ │ │ │ │ │ Local DRAM │ │ │ │ ││ │ │ │ │ │ │ (Processing) │ │ │ │ ││ │ │ │ │ │ └────────────────┘ │ │ │ ││ │ │ │ │ └──────────────────────┘ │ │ ││ │ │ │ └─────────────────────────────────────────────────┘ │ ││ │ │ │ │ │ ││ │ │ │ ┌─────────────────────┴───────────────────────────┐ │ ││ │ │ │ │ Flash Controller │ │ ││ │ │ │ └─────────────────────────────────────────────────┘ │ ││ │ │ │ │ │ ││ │ │ │ ┌─────────────────────┴───────────────────────────┐ │ ││ │ │ │ │ NAND Flash Array │ │ ││ │ │ │ │ [Die][Die][Die][Die][Die][Die][Die][Die] │ │ ││ │ │ │ └─────────────────────────────────────────────────┘ │ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ USE CASES: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ 1. Transparent Compression/Encryption ││ │ │ ┌────────┐ ┌─────────────┐ ┌────────┐ ││ │ │ │ Data │───►│ Compress/ │───►│ NAND │ ││ │ │ │(plain) │ │ Encrypt HW │ │(smaller)│ ││ │ │ └────────┘ └─────────────┘ └────────┘ ││ │ │ ││ │ │ 2. Database Query Offload (e.g., Samsung SmartSSD) ││ │ │ SELECT * FROM table WHERE column > 100 ││ │ │ ┌────────────────────────────────────────────────┐ ││ │ │ │ CSD scans data internally, returns only matches│ ││ │ │ │ Host receives: 1000 rows instead of 1M rows │ ││ │ │ └────────────────────────────────────────────────┘ ││ │ │ ││ │ │ 3. Video Transcoding ││ │ │ ┌────────┐ ┌─────────────┐ ┌────────┐ ││ │ │ │ H.264 │───►│ Transcode │───►│ H.265 │ ││ │ │ │ Video │ │ Engine │ │ Video │ ││ │ │ └────────┘ └─────────────┘ └────────┘ ││ │ │ (No host CPU/memory involvement) ││ │ │ ││ │ │ 4. AI Inference at Storage ││ │ │ • Image classification on stored images ││ │ │ • Anomaly detection on log files ││ │ │ • Embedding generation for vector search ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ SNIA COMPUTATIONAL STORAGE ARCHITECTURE: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ CSE Types (Computational Storage Engine): ││ │ │ ││ │ │ ┌─────────────────┬─────────────────────────────────────┐ ││ │ │ │ Fixed CSE │ Hardcoded function (compression) │ ││ │ │ │ │ Simple, efficient, limited │ ││ │ │ ├─────────────────┼─────────────────────────────────────┤ ││ │ │ │ Programmable CSE│ User-downloadable programs │ ││ │ │ │ │ Flexible (eBPF, WASM, custom) │ ││ │ │ └─────────────────┴─────────────────────────────────────┘ ││ │ │ ││ │ │ NVMe Command Extensions: ││ │ │ • Computational Programs (download code) ││ │ │ • Computational Execute (run program) ││ │ │ • Memory Ranges (define input/output regions) ││ │ └─────────────────────────────────────────────────────────────┘│ └─────────────────────────────────────────────────────────────────┘
Zoned Namespaces (ZNS)
Zoned Namespaces is an NVMe specification that divides SSD capacity into sequential-write zones, aligning with flash memory's internal structure. Unlike conventional SSDs that hide flash complexity behind a block interface (requiring expensive garbage collection), ZNS exposes zones that must be written sequentially and explicitly reset. This reduces write amplification, improves endurance, and decreases SSD cost by eliminating overprovisioning—ideal for append-heavy workloads like log-structured databases.
┌─────────────────────────────────────────────────────────────────┐ │ ZONED NAMESPACES (ZNS) │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ CONVENTIONAL SSD vs ZNS: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ Conventional SSD (Block Interface): ││ │ │ ┌───────────────────────────────────────────────────────┐ ││ │ │ │ Host writes randomly to any LBA │ ││ │ │ │ ┌───┬───┬───┬───┬───┬───┬───┬───┐ │ ││ │ │ │ │ A │ │ B │ │ C │ │ D │ │ Random writes │ ││ │ │ │ └───┴───┴───┴───┴───┴───┴───┴───┘ │ ││ │ │ │ │ │ ││ │ │ │ ▼ │ ││ │ │ │ SSD FTL (Flash Translation Layer): │ ││ │ │ │ • Maps random writes to sequential flash │ ││ │ │ │ • Garbage collection required │ ││ │ │ │ • 20-30% overprovisioning needed │ ││ │ │ │ • Write amplification: 2-5x │ ││ │ │ └───────────────────────────────────────────────────────┘ ││ │ │ ││ │ │ ZNS SSD (Zoned Interface): ││ │ │ ┌───────────────────────────────────────────────────────┐ ││ │ │ │ Host writes sequentially within zones │ ││ │ │ │ ┌─────────────────┬─────────────────┬───────────────┐│ ││ │ │ │ │ Zone 0 │ Zone 1 │ Zone 2 ││ ││ │ │ │ │ [A][B][C][D]──► │ [E][F][G]──► │ [empty] ││ ││ │ │ │ │ (full) │ (open) │ (empty) ││ ││ │ │ │ └─────────────────┴─────────────────┴───────────────┘│ ││ │ │ │ │ ││ │ │ │ • No FTL garbage collection │ ││ │ │ │ • Minimal overprovisioning (3-5%) │ ││ │ │ │ • Write amplification: ~1x │ ││ │ │ │ • Lower cost, higher endurance │ ││ │ │ └───────────────────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ ZONE STATES: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ ┌─────────┐ Zone Open ┌─────────┐ ││ │ │ │ Empty │ ──────────────► │ Open │ ││ │ │ │ │ │(writing)│ ││ │ │ └────┬────┘ └────┬────┘ ││ │ │ │ │ ││ │ │ │ │ Write to end ││ │ │ │ │ or Zone Finish ││ │ │ │ ▼ ││ │ │ │ ┌─────────┐ ││ │ │ │ │ Full │ ││ │ │ │ │ │ ││ │ │ │ └────┬────┘ ││ │ │ │ │ ││ │ │ │ Zone Reset │ Zone Reset ││ │ │ │◄──────────────────────────┘ ││ │ │ ││ │ │ Commands: ││ │ │ • Zone Append: Write at current write pointer ││ │ │ • Zone Finish: Close zone, mark full ││ │ │ • Zone Reset: Erase zone, return to empty ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ ZNS ZONE STRUCTURE: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ Zone (typically 256MB - 2GB): ││ │ │ ┌───────────────────────────────────────────────────────┐ ││ │ │ │ │ ││ │ │ │ Zone Start LBA Zone Capacity │ ││ │ │ │ │ │ │ ││ │ │ │ ▼ ▼ │ ││ │ │ │ ┌────┬────┬────┬────┬────┬────┬────┬────┬────┬────┐ │ ││ │ │ │ │████│████│████│████│████│░░░░│░░░░│░░░░│░░░░│░░░░│ │ ││ │ │ │ └────┴────┴────┴────┴────┴────┴────┴────┴────┴────┘ │ ││ │ │ │ ▲ │ ││ │ │ │ │ │ ││ │ │ │ Write Pointer │ ││ │ │ │ (next write location) │ ││ │ │ │ │ ││ │ │ │ ████ = Written data (cannot be overwritten) │ ││ │ │ │ ░░░░ = Available for sequential write │ ││ │ │ └───────────────────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ IDEAL WORKLOADS: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ • Log-structured file systems (F2FS, Btrfs) ││ │ │ • Log-structured merge trees (RocksDB, LevelDB) ││ │ │ • Write-ahead logs (databases) ││ │ │ • Object storage (Ceph BlueStore) ││ │ │ • Time-series databases ││ │ │ • Streaming data ingestion ││ │ │ ││ │ │ NOT suitable for: ││ │ │ • Random in-place updates ││ │ │ • Traditional file systems (ext4, XFS) ││ │ │ • Databases with heavy UPDATE workloads ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ WRITE AMPLIFICATION COMPARISON: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ Workload: 100GB random writes ││ │ │ ││ │ │ Conventional SSD: ││ │ │ ┌────────────────────────────────────────────────────────┐││ │ │ │ Host writes: 100 GB │││ │ │ │ Flash writes: 300 GB (3x WA from GC) │││ │ │ │ Effective endurance: 33% │││ │ │ └────────────────────────────────────────────────────────┘││ │ │ ││ │ │ ZNS SSD (with zone-aware application): ││ │ │ ┌────────────────────────────────────────────────────────┐││ │ │ │ Host writes: 100 GB │││ │ │ │ Flash writes: 100 GB (1x WA, no GC) │││ │ │ │ Effective endurance: 100% │││ │ │ └────────────────────────────────────────────────────────┘││ │ └─────────────────────────────────────────────────────────────┘│ └─────────────────────────────────────────────────────────────────┘
Key-Value SSDs (KV-SSD)
Key-Value SSDs implement a native key-value interface directly in the storage device, eliminating the file system and block layer overhead. Instead of read/write to LBAs, applications use PUT/GET/DELETE operations with arbitrary keys. This reduces software stack complexity, improves performance for KV workloads by 2-10x, and enables storage-level features like variable-size values and atomic operations—Samsung's KV-SSD and emerging NVMe KV command sets standardize this approach.
┌─────────────────────────────────────────────────────────────────┐ │ KEY-VALUE SSDs │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ TRADITIONAL vs KV-SSD STACK: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ Traditional Block Storage: KV-SSD: ││ │ │ ┌───────────────────────┐ ┌───────────────────────┐ ││ │ │ │ Application │ │ Application │ ││ │ │ │ (key-value store) │ │ (key-value store) │ ││ │ │ ├───────────────────────┤ ├───────────────────────┤ ││ │ │ │ KV Library │ │ │ ││ │ │ │ (RocksDB, etc) │ │ Direct KV API │ ││ │ │ ├───────────────────────┤ │ (PUT/GET/DELETE) │ ││ │ │ │ File System │ │ │ ││ │ │ │ (ext4, XFS) │ └───────────┬───────────┘ ││ │ │ ├───────────────────────┤ │ ││ │ │ │ Block Layer │ │ ││ │ │ ├───────────────────────┤ │ ││ │ │ │ NVMe Driver │ │ ││ │ │ ├───────────────────────┤ ┌───────────┴───────────┐ ││ │ │ │ NVMe SSD │ │ KV-SSD │ ││ │ │ │ (Block interface) │ │ (Native KV interface)│ ││ │ │ └───────────────────────┘ └───────────────────────┘ ││ │ │ ││ │ │ Layers eliminated: 4 Layers: 2 ││ │ │ Latency overhead: High Latency: Minimal ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ KV-SSD OPERATIONS: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ KV-SSD Device │ ││ │ │ │ │ ││ │ │ │ Commands: │ ││ │ │ │ ┌─────────────────────────────────────────────┐ │ ││ │ │ │ │ STORE (key, value) │ │ ││ │ │ │ │ Store value with given key │ │ ││ │ │ │ ├─────────────────────────────────────────────┤ │ ││ │ │ │ │ RETRIEVE (key) → value │ │ ││ │ │ │ │ Get value for key │ │ ││ │ │ │ ├─────────────────────────────────────────────┤ │ ││ │ │ │ │ DELETE (key) │ │ ││ │ │ │ │ Remove key-value pair │ │ ││ │ │ │ ├─────────────────────────────────────────────┤ │ ││ │ │ │ │ EXIST (key) → boolean │ │ ││ │ │ │ │ Check if key exists │ │ ││ │ │ │ ├─────────────────────────────────────────────┤ │ ││ │ │ │ │ ITERATE (prefix) → keys[] │ │ ││ │ │ │ │ List keys with prefix │ │ ││ │ │ │ └─────────────────────────────────────────────┘ │ ││ │ │ │ │ ││ │ │ │ Key: Variable length (up to 255 bytes typical) │ ││ │ │ │ Value: Variable length (up to 2MB typical) │ ││ │ │ └───────────────────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ KV-SSD INTERNAL ARCHITECTURE: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ KV-SSD Controller │ ││ │ │ │ ┌─────────────────────────────────────────────────┐ │ ││ │ │ │ │ KV Processing Engine │ │ ││ │ │ │ │ │ │ ││ │ │ │ │ ┌───────────────┐ ┌───────────────────────┐ │ │ ││ │ │ │ │ │ Hash Index │ │ B-Tree / LSM-Tree │ │ │ ││ │ │ │ │ │ (in DRAM) │ │ (for ordering) │ │ │ ││ │ │ │ │ └───────────────┘ └───────────────────────┘ │ │ ││ │ │ │ │ │ │ ││ │ │ │ │ ┌───────────────────────────────────────────┐ │ │ ││ │ │ │ │ │ Value Storage Manager │ │ │ ││ │ │ │ │ │ • Variable-size allocation │ │ │ ││ │ │ │ │ │ • Garbage collection │ │ │ ││ │ │ │ │ │ • Wear leveling │ │ │ ││ │ │ │ │ └───────────────────────────────────────────┘ │ │ ││ │ │ │ └─────────────────────────────────────────────────┘ │ ││ │ │ │ │ │ ││ │ │ │ ┌───────────────────────┴───────────────────────┐ │ ││ │ │ │ │ NAND Flash Array │ │ ││ │ │ │ │ [Values stored directly, no block mapping] │ │ ││ │ │ │ └───────────────────────────────────────────────┘ │ ││ │ │ └───────────────────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ PERFORMANCE BENEFITS: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ Workload: Random 4KB KV operations ││ │ │ ││ │ │ ┌────────────────────┬──────────────┬──────────────────┐ ││ │ │ │ Metric │ Block + FS │ KV-SSD │ ││ │ │ ├────────────────────┼──────────────┼──────────────────┤ ││ │ │ │ Read Latency │ 150 µs │ 50 µs │ ││ │ │ │ Write Latency │ 200 µs │ 60 µs │ ││ │ │ │ IOPS (read) │ 200K │ 800K │ ││ │ │ │ IOPS (write) │ 100K │ 400K │ ││ │ │ │ CPU Utilization │ 40% │ 10% │ ││ │ │ │ Software Overhead │ High │ Minimal │ ││ │ │ └────────────────────┴──────────────┴──────────────────┘ ││ │ │ ││ │ │ Why faster: ││ │ │ • No file system overhead ││ │ │ • No block layer translation ││ │ │ • No journaling ││ │ │ • Optimized hash/tree structures in device ││ │ │ • Variable-size values (no padding to 4K blocks) ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ NVMe KV COMMAND SET (Emerging Standard): │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ NVMe 2.0 includes optional KV Command Set: ││ │ │ ││ │ │ Admin Commands: ││ │ │ • Identify KV Namespace ││ │ │ ││ │ │ I/O Commands: ││ │ │ ┌──────────┬─────────────────────────────────────────┐ ││ │ │ │ Opcode │ Command │ ││ │ │ ├──────────┼─────────────────────────────────────────┤ ││ │ │ │ 0x81 │ KV Store │ ││ │ │ │ 0x82 │ KV Retrieve │ ││ │ │ │ 0x83 │ KV Delete │ ││ │ │ │ 0x84 │ KV Exist │ ││ │ │ │ 0x85 │ KV List │ ││ │ │ └──────────┴─────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ └─────────────────────────────────────────────────────────────────┘
// KV-SSD interface simulation class KVSSDevice { constructor(capacity) { this.capacity = capacity; this.store = new Map(); this.stats = { reads: 0, writes: 0, deletes: 0, bytesWritten: 0, bytesRead: 0 }; } // STORE command - O(1) average async store(key, value, options = {}) { if (key.length > 255) throw new Error('Key too long (max 255 bytes)'); if (value.length > 2 * 1024 * 1024) throw new Error('Value too large (max 2MB)'); const existed = this.store.has(key); this.store.set(key, { value: Buffer.from(value), timestamp: Date.now(), options }); this.stats.writes++; this.stats.bytesWritten += value.length; return { success: true, existed }; } // RETRIEVE command - O(1) average async retrieve(key, options = {}) { const entry = this.store.get(key); if (!entry) { return { found: false, value: null }; } this.stats.reads++; this.stats.bytesRead += entry.value.length; // Support partial read if (options.offset !== undefined && options.length !== undefined) { return { found: true, value: entry.value.slice(options.offset, options.offset + options.length) }; } return { found: true, value: entry.value }; } // DELETE command - O(1) average async delete(key) { const existed = this.store.delete(key); this.stats.deletes++; return { success: true, existed }; } // EXIST command - O(1) async exist(key) { return { exists: this.store.has(key) }; } // LIST/ITERATE command - O(n) where n = matching keys async list(prefix, options = {}) { const maxKeys = options.maxKeys || 1000; const keys = []; for (const key of this.store.keys()) { if (key.startsWith(prefix)) { keys.push(key); if (keys.length >= maxKeys) break; } } return { keys, truncated: keys.length >= maxKeys }; } // Batch operations (atomic) async batch(operations) { const results = []; // In real KV-SSD, this would be atomic for (const op of operations) { switch (op.type) { case 'store': results.push(await this.store(op.key, op.value)); break; case 'delete': results.push(await this.delete(op.key)); break; } } return results; } getStats() { return { ...this.stats, keyCount: this.store.size, avgValueSize: this.stats.bytesWritten / Math.max(1, this.stats.writes) }; } } // Usage comparison: Block vs KV-SSD async function compareApproaches() { // KV-SSD approach - direct const kvSSD = new KVSSDevice(1024 * 1024 * 1024); console.time('KV-SSD writes'); for (let i = 0; i < 10000; i++) { await kvSSD.store(`user:${i}`, JSON.stringify({ id: i, name: `User ${i}` })); } console.timeEnd('KV-SSD writes'); console.time('KV-SSD reads'); for (let i = 0; i < 10000; i++) { await kvSSD.retrieve(`user:${i}`); } console.timeEnd('KV-SSD reads'); console.log('Stats:', kvSSD.getStats()); }