Every storage array I’ve ever configured comes down, eventually, to a set of physical or virtual disks sitting in a shelf or an SSD slot. It’s easy to treat disks as interchangeable commodity parts, but the differences between HDD and SSD architectures — and between the interfaces connecting them (SATA, SAS, NVMe) — have real consequences for performance, reliability, and cost design. This article covers the disk types I work with regularly, their internal components, and the features that actually drive purchasing and architecture decisions.
Hard Disk Drives (HDDs)
How HDDs Work
An HDD stores data magnetically on spinning platters, read and written by a moving actuator arm with read/write heads flying microscopically above the platter surface.
Core HDD Components
- Platters — rigid magnetic disks, typically multiple stacked on a single spindle; higher-capacity drives use more platters and higher areal density per platter.
- Spindle motor — spins the platters at a constant speed (commonly 7200 RPM for enterprise nearline drives, 10K/15K RPM for legacy high-performance drives, though 15K drives have largely been displaced by SSDs for performance-tier workloads).
- Actuator arm and read/write heads — position magnetic heads over specific tracks; head movement (seek time) is the dominant latency factor in HDD random I/O performance.
- Drive controller/PCB — manages command processing, caching, and the interface protocol (SATA/SAS).
- Onboard cache (DRAM) — buffers reads/writes; enterprise drives typically include larger caches (128MB-512MB+) than consumer drives.
HDD Performance Characteristics
Typical enterprise nearline HDD (7200 RPM, SAS):
- Random IOPS (4K): ~150-200 IOPS
- Sequential throughput: ~250 MB/s
- Average latency: ~4.2ms (rotational) + seek time
- Typical capacity range: 4TB - 22TB+ (as of recent generations)
I still specify HDDs heavily for capacity-tier and archival workloads, where the cost-per-terabyte advantage over flash remains significant, even as flash pricing continues to fall.
HDD Reliability Features
- RV (Rotational Vibration) sensors — compensate for vibration from adjacent drives in dense shelves, a feature I specifically check for in high-density JBOD/JBOF deployments.
- Helium-sealed enclosures — used in higher-capacity enterprise drives; helium’s lower density reduces friction and turbulence, enabling more platters per drive and improved power efficiency.
- SMART (Self-Monitoring, Analysis, and Reporting Technology) — reports predictive failure indicators (reallocated sectors, pending sector counts) that I monitor proactively rather than waiting for a hard failure.
# Checking SMART health on Linux
smartctl -a /dev/sda
# Key attributes I watch closely
smartctl -A /dev/sda | grep -E "Reallocated_Sector|Pending_Sector|UDMA_CRC"
Solid State Drives (SSDs)
How SSDs Work
SSDs store data in NAND flash memory cells, with no moving mechanical parts, using a controller to manage wear leveling, garbage collection, and error correction.
Core SSD Components
- NAND flash chips — the actual storage medium, organized in various architectures (SLC, MLC, TLC, QLC) that trade cost-per-GB against endurance and performance.
- SSD controller — manages the Flash Translation Layer (FTL), wear leveling, garbage collection, and error correction (LDPC/BCH codes).
- DRAM cache (in DRAM-based SSDs) — stores the FTL mapping table for fast lookups; some cost-optimized “DRAM-less” SSDs use host memory buffer (HMB) instead, generally with a performance trade-off.
- Power loss protection capacitors — enterprise SSDs include onboard capacitors to flush in-flight writes to flash during unexpected power loss, a feature I consider non-negotiable for any production storage SSD.
NAND Flash Types
| NAND Type | Bits per Cell | Endurance (relative) | Cost per GB | Typical Use |
|---|---|---|---|---|
| SLC | 1 | Highest | Highest | Legacy enterprise, cache tiers |
| MLC | 2 | High | High | Performance-tier enterprise |
| TLC | 3 | Moderate | Moderate | Mainstream enterprise/consumer |
| QLC | 4 | Lower | Lowest | Capacity-tier, read-heavy workloads |
I match NAND type to workload write intensity — QLC is excellent and cost-effective for read-heavy or archival flash tiers, but I avoid it for write-intensive database or logging workloads where endurance matters more.
SSD Endurance Metrics
- DWPD (Drive Writes Per Day) — how many times the drive’s full capacity can be rewritten per day over its warranty period; enterprise write-intensive drives might be rated 3-10 DWPD, while read-intensive drives might be rated 0.3-1 DWPD.
- TBW (Terabytes Written) — total lifetime write endurance expressed as a capacity figure, common on both consumer and enterprise SSD spec sheets.
Example endurance comparison:
- Read-intensive enterprise SSD: 1 DWPD, 3.84TB capacity → ~3.84TB/day sustainable writes
- Mixed-use enterprise SSD: 3 DWPD, 3.84TB capacity → ~11.5TB/day sustainable writes
- Write-intensive enterprise SSD: 10 DWPD, 3.84TB capacity → ~38.4TB/day sustainable writes
Disk Interfaces
SATA (Serial ATA)
- Speed: Up to 6 Gbps (SATA III).
- Use case: Cost-sensitive capacity-tier storage, both HDD and entry-level SSD; largely displaced by SAS/NVMe in performance-sensitive enterprise designs, though still common for bulk nearline HDD deployments.
SAS (Serial Attached SCSI)
- Speed: 12 Gbps (SAS-3), 24 Gbps (SAS-4).
- Use case: The enterprise standard for both HDDs and SSDs in shared/dual-path storage array environments; SAS supports dual-port connectivity, allowing a drive to be accessed via two independent paths simultaneously — a feature SATA fundamentally lacks, making SAS the preferred choice for high-availability shared storage enclosures.
NVMe (Non-Volatile Memory Express)
- Speed: PCIe-attached, with per-drive bandwidth scaling with PCIe generation and lane count (e.g., a PCIe Gen4 x4 NVMe SSD can exceed 7 GB/s sequential throughput).
- Key architectural advantage: NVMe was designed from the ground up for flash, supporting massively parallel command queues (up to 64K queues, 64K commands per queue) versus SATA/SAS’s legacy single-queue SCSI command model — this is the primary reason NVMe SSDs dramatically outperform SAS/SATA SSDs under high-concurrency workloads.
- Use case: Performance-tier and all-flash array front-line storage, increasingly extended across the network via NVMe-oF for disaggregated architectures.
Interface Comparison (approximate):
SATA III: 6 Gbps, single queue, single path
SAS-3: 12 Gbps, single queue (SCSI), dual path
NVMe (PCIe Gen4 x4): ~64 Gbps raw lane bandwidth, 64K queues/64K depth each
Drive Form Factors
| Form Factor | Common Use |
|---|---|
| 3.5″ | High-capacity nearline HDDs |
| 2.5″ | SAS/SATA SSDs and 10K/15K HDDs, higher density per shelf |
| M.2 | NVMe SSDs in boot/cache roles, some compute-adjacent storage |
| U.2/U.3 | Hot-swappable enterprise NVMe SSDs in standard 2.5″ drive bay form factor |
| EDSFF (E1.S, E3.S, etc.) | Next-generation NVMe form factors designed for higher density and better thermal characteristics than U.2 |
I’ve seen U.3 become the practical enterprise standard for hot-swap NVMe specifically because it maintains backward compatibility with SAS/SATA bay designs while enabling NVMe — a major deployment convenience during the flash transition.
RAID and Drive Grouping Considerations by Disk Type
- HDD RAID rebuild times — a critical consideration; rebuilding a failed high-capacity (18TB+) HDD in a RAID 5/6 group can take many hours to over a day, during which the array runs in a degraded, more failure-vulnerable state. This is a major reason I favor RAID 6 or erasure coding over RAID 5 for large-capacity HDD pools.
- SSD rebuild times — dramatically faster due to higher throughput, reducing the exposure window during a rebuild, though write amplification during heavy rebuild I/O is still a factor I account for with QLC-based pools specifically.
- Mixed-media pools (tiering) — many modern arrays automatically tier hot data to flash and cold data to HDD within the same pool, and I always verify the array’s tiering algorithm and monitoring visibility before relying on it for performance-critical workloads.
Drive Health Monitoring and Predictive Failure
# HDD - SMART monitoring
smartctl -a /dev/sda
# NVMe - health/log page monitoring
nvme smart-log /dev/nvme0
# Key NVMe health indicators I track
nvme smart-log /dev/nvme0 | grep -E "percentage_used|media_errors|critical_warning"
- HDD: reallocated sector count, pending sector count, and CRC error counts are my primary predictive indicators.
- SSD/NVMe:
percentage_used(wear indicator relative to rated endurance) andmedia_errorsare the metrics I monitor most closely, alongside temperature (flash endurance and performance degrade at sustained high temperatures).
Common Mistakes I See
- Deploying QLC SSDs for write-intensive database workloads and being surprised by premature wear.
- Using RAID 5 on large-capacity HDDs without accounting for the extended, vulnerable rebuild window.
- Ignoring SMART/NVMe health telemetry until a drive fails outright, missing the predictive warning period.
- Mixing drive interface types (SATA vs SAS) within the same RAID group where the array/controller allows it but performance characteristics don’t match.
- Underestimating how much dual-port SAS connectivity matters for high-availability shared enclosure designs compared to SATA.
Frequently Asked Questions
Are HDDs obsolete now that flash is so much cheaper? Not yet — for large-capacity, lower-performance-requirement archival and nearline tiers, HDDs still offer a meaningful cost-per-terabyte advantage, though the gap continues to narrow.
What’s the real practical difference between SAS and SATA SSDs? Beyond raw speed, the biggest practical difference is dual-port support — SAS SSDs can be accessed via two independent paths for high-availability shared storage designs, while SATA is fundamentally single-path.
Why does NVMe outperform SAS SSDs so dramatically under load? It comes down to the command queueing architecture — NVMe’s massively parallel queue design (up to 64K queues) removes the bottleneck inherent in SAS/SATA’s legacy single-queue SCSI command model, particularly visible under high-concurrency workloads.
Is QLC flash reliable enough for production enterprise use? Yes, for the right workload — read-heavy or capacity-tier use cases are a great fit, but I avoid QLC for write-intensive workloads where its lower endurance rating becomes a real operational risk.
Summary
Disk types — HDD and SSD, across SATA, SAS, and NVMe interfaces — each bring distinct performance, endurance, and reliability characteristics that should directly drive architecture decisions rather than being treated as interchangeable commodity choices. Understanding the internal components (platters and actuators for HDDs; NAND type, controller, and power-loss protection for SSDs) and interface-level differences (queue depth, dual-port support, raw bandwidth) is what separates a storage design that performs predictably under load from one that quietly underperforms until a workload spike exposes the gap.
References
- SNIA Solid State Storage and NVMe technical resources (snia.org)
- Seagate and Western Digital enterprise HDD technology documentation (seagate.com, westerndigital.com)
- NVM Express specification and technical resources (nvmexpress.org)
- Dell EMC and HPE enterprise storage media selection guides (dell.com, hpe.com)
- Samsung and Micron enterprise SSD technical whitepapers