Understanding Storage I/O Flow, Performance Metrics, and SQL Server I/O Types

Performance has been a driving force in IT for decades, and every new technology—hardware or software—aims to improve it; this article introduces the storage I/O (Block) flow to reveal how I/O paths affect storage performance.

Storage I/O is the process of reading from or writing to memory, whether volatile (RAM) or persistent (disk). In enterprise environments a single I/O traverses multiple nodes, each possibly splitting the request into smaller I/Os before reaching the destination.

The typical I/O path includes the following nodes:

File System – maps files to blocks and sends requests to the HBA.

HBA – converts the request into Fibre Channel frames (≤2 KB) and forwards them to the FC Switch.

FC Switch – transports frames over the FC fabric to the storage front‑end adapter (FA).

Storage FA – re‑encapsulates frames and passes them to the storage array cache.

Storage Array Cache – either acknowledges the write (write‑back) or flushes data to the Disk Adapter (write‑through).

Disk Adapter – splits the I/O according to the RAID level and finally writes to the physical disks.

The time‑consuming stages of a complete I/O are:

CPU–RAM – host file system to HBA processing.

HBA–FA – transmission over the fibre network.

FA–Cache – time to write into the storage cache.

DA–Drive – time to persist data on the physical disk.

The cache in a storage array is critical; its size and efficiency directly influence I/O latency. Even with an optimal cache, typical host‑side I/O latency ranges from 1 ms to 3 ms because of data‑header processing and concurrency.

Data‑header processing adds overhead for negotiation, acknowledgments, CRC checks, and other control information at each node. Concurrency causes queueing delays when many I/Os traverse the same path simultaneously.

Key take‑aways about I/O flow and performance:

The I/O path passes through HBA, FC network, FA, cache, back‑end controller, and finally the disk, with the disk being the biggest latency contributor.

Cache size and policies are major performance indicators for storage arrays.

High concurrency often leads to queue delays, making actual I/O speed far below theoretical limits.

Improving disk speed (e.g., SSDs) yields the most noticeable performance gains.

Choosing an appropriate RAID level can significantly affect I/O latency.

IOPS (operations per second) measures how many I/O operations a system can handle, while throughput (MB/s) measures the amount of data transferred per second. The two are linearly related by the I/O size:

Throughput (MB/s) = IOPS × (KB per I/O) / 1024

For example, 10 × 10 K SAS disks providing 140 IOPS each (total 1400 IOPS) yield:

1400 × 64 KB / 1024 = 87.5 MB/s

1400 × 128 KB / 1024 = 175 MB/s

1400 × 256 KB / 1024 = 350 MB/s

When planning storage performance, both IOPS and throughput must be considered; the metric that reaches the physical limit first determines the overall capability.

Database Storage I/O Types and Configuration

SQL Server interacts with storage through physical I/O operations, which are typically 8 KB pages. Physical I/O occurs when data is not cached, during log writes, checkpoints, lazy writes, or special operations such as backups and index rebuilds.

Key observations for SQL Server storage:

Distributing data files across multiple LUNs improves concurrency and performance.

OLTP workloads are IOPS‑bound, whereas OLAP/DDS workloads are throughput‑bound.

Understanding RAID write penalties helps choose the right RAID level for data and log files.

Leverage storage‑side features like write/read cache ratios, FAST tiering, and appropriate cache policies.

Validate storage performance with stress‑testing tools that simulate realistic I/O patterns.

In summary, storage performance hinges on cache design, disk speed, I/O size, and proper configuration; for SQL Server, aligning storage architecture with workload characteristics is essential for optimal I/O efficiency.