Secondary Storage - Persistent Storage

Introduction

Secondary storage provides persistent data storage that survives power loss — unlike RAM, which loses its contents when the computer shuts down. The operating system's storage management subsystem bridges the enormous performance gap between fast volatile memory (nanoseconds) and slow persistent storage (milliseconds for HDDs, microseconds for SSDs), making both appear as a unified, accessible resource to applications.

Understanding secondary storage is essential because it is the bottleneck in most computer systems. CPU speed has increased by millions of times since the 1970s, but disk seek times improved only by a factor of about 10. This disparity drives most OS storage optimizations — caching, prefetching, scheduling, and buffering all exist to hide storage latency.

The Storage Hierarchy

The OS uses faster levels as caches for slower levels — the page cache keeps frequently accessed disk data in RAM, reducing the need for slow disk reads.

Magnetic Hard Disk Drives (HDD)

Despite SSDs gaining ground, HDDs remain important for bulk storage due to cost (3-5 cents per GB vs 10-25 cents for SSD).

Physical Structure

• Platter: Circular disk coated with magnetic material (data stored as magnetic orientation)
• Track: Concentric circles on a platter surface
• Sector: Smallest addressable unit (traditionally 512 bytes, modern: 4KB)
• Cylinder: All tracks at the same radial position across all platters
• Disk arm: Moves read/write head to the correct track

Access Time Components

• Seek time: Time to move arm to correct track (2-15ms, most expensive)
• Rotational latency: Time for sector to spin under head (average = half rotation)
• 7200 RPM: avg latency = 4.17ms
• 15000 RPM: avg latency = 2ms
• Transfer time: Time to read/write data once head is positioned (typically < 1ms for a sector)

Why Disk Scheduling Matters

Since seek time dominates, the ORDER in which disk requests are serviced dramatically affects performance. Reading 100 random sectors might take 500ms on HDD but only 5ms on SSD. This is why disk scheduling algorithms (SCAN, C-SCAN, LOOK) exist — they minimize total head movement.

Solid State Drives (SSD)

SSDs use NAND flash memory — no moving parts, no seek time, no rotational latency.

SSD Internal Architecture

SSD Characteristics

• No seek time: Any location accessed equally fast (random reads ≈ sequential reads)
• Read vs Write asymmetry: Reads are fast (50μs); writes require erasing a full block first
• Write amplification: Updating a single page may require reading, erasing, and rewriting an entire block (128-512 pages)
• Limited write endurance: Each cell can be written 1,000-100,000 times (depending on technology: SLC > MLC > TLC > QLC)
• TRIM command: OS tells SSD which blocks are no longer in use, allowing efficient garbage collection

OS Implications of SSDs

The OS must handle SSDs differently from HDDs:

• Disk scheduling is unnecessary (no seek time to optimize)
• TRIM support required to maintain SSD performance over time
• Write patterns should be aligned to page/block boundaries
• Wear leveling is handled by SSD firmware, but OS can help by reducing write amplification

Storage Interfaces

NVMe advantage: SATA was designed for spinning disks (single queue, 32 commands). NVMe uses PCIe directly with 64K queues of 64K commands each — designed for SSD parallelism.

How the OS Manages Secondary Storage

Block Device Abstraction

The OS presents all storage devices (HDD, SSD, USB) as block devices — arrays of fixed-size blocks addressable by number:

Page Cache (Buffer Cache)

The OS keeps recently accessed disk blocks in RAM:

• Read: Check page cache first → if found (cache hit), return from RAM → if not (cache miss), read from disk and store in cache
• Write: Write to page cache (marked "dirty") → flush to disk periodically or on sync

I/O Schedulers

Linux provides different I/O schedulers for different storage types:

• none/noop: No reordering (best for NVMe SSDs — no seek time to optimize)
• mq-deadline: Ensures no request waits too long (good for SSDs with latency guarantees)
• BFQ (Budget Fair Queuing): Fair bandwidth distribution among processes (good for interactive HDD systems)

Key Takeaways

• Secondary storage provides persistence but is orders of magnitude slower than RAM
• HDD performance is dominated by mechanical seek time — scheduling matters significantly
• SSDs eliminate mechanical delays but have write amplification and limited endurance
• NVMe interface unlocks SSD parallelism that SATA cannot exploit
• The OS page cache bridges the speed gap by keeping hot data in RAM
• Different I/O schedulers optimize for different storage characteristics (HDD vs SSD)
• Understanding storage tradeoffs helps explain why databases, file systems, and caches are designed the way they are