This page provides an introduction to the different block protocols, how they work and compares their features, capabilities and benefits.
What is block storage?
Block storage protocols define how hosts (also known as initiators) access raw blocks of data on a storage device over a network or direct connection as if they were local disks. Instead of managing files or objects, the host sees a logical unit (LUN) or namespace composed of fixed-size blocks and layers its own filesystem or database structure on top. This model is popular for databases, virtual machines, and latency‑sensitive transactional workloads, because it offers predictable performance, tight control over layout, and broad OS/application compatibility. Customers often choose block storage when they want maximum flexibility at the host layer (their choice of filesystem, volume manager, clustering stack) and fine‑grained performance and QoS control.
Traditional block protocols include iSCSI and Fibre Channel (FC). iSCSI encapsulates SCSI commands in TCP/IP, running over standard Ethernet networks, which makes it cost‑effective, easy to deploy, and attractive for organizations that want to leverage existing IP networking skills and hardware. Fibre Channel, in contrast, uses a purpose‑built, lossless storage network with dedicated HBAs and switches. Customers choose FC for low latency, high reliability, and deterministic performance in mission‑critical SAN environments, accepting higher cost and specialized networking expertise in exchange for those qualities.
Newer protocols use the NVMe command set over different transports to reduce overhead and improve efficiency. NVMe/TCP carries NVMe over standard TCP/IP, aiming to combine NVMe’s low‑latency, parallel I/O model with the operational simplicity and ubiquity of Ethernet/IP. NVMe/RDMA (often over InfiniBand or RoCE) uses Remote Direct Memory Access to bypass parts of the network stack, yielding very low latency and high throughput for demanding workloads like high‑frequency databases or large virtualization clusters. NVMe/RoCE (NVMe over RDMA over Converged Ethernet) specifically uses a lossless Ethernet fabric with Data Center Bridging (DCB), giving near‑FC‑class latency and efficiency while still running on Ethernet infrastructure, albeit with more stringent network design and tuning requirements.
Compared with file (NFS/SMB) and object (S3‑style) protocols, block protocols offer finer control, lower protocol overhead, and generally better latency at the cost of less built‑in data management. File and object storage usually provide richer namespaces, multi‑client sharing semantics, and application‑level features (e.g., POSIX file locks, object metadata, HTTP access), which can simplify application design and data sharing. Block storage requires the host to manage filesystems, sharing, and consistency, and can be more complex to scale out for many independent clients.
Customers typically choose block for performance‑critical, tightly managed infrastructure (databases, virtual machine clusters). Other protocols and transports are chosen for their use-case suitability,such as file for shared user and application data, and object for scalable, cost‑optimized, and cloud‑integrated storage.
Block Protocols Comparison
| Protocol | Networks | Specialized Hardware? | Supported Speeds | Boot From SAN | Performance | When to Use? |
|---|---|---|---|---|---|---|
| iSCSI | Ethernet + TCP/IP; L3 routing possible but SAN designs typically keep traffic in dedicated L2/VLANs (avoid routing where feasible). | No. Standard Ethernet NICs and switches. | 10/25/40/100 GbE iSCSI ports. | Yes (platform‑dependent, common). | Highest overhead; host‑CPU heavy vs other options; latency typically sub‑ms to low ms. | Simple, mature, flexible; SCSI limits queues vs NVMe; sensitive to oversubscription—keep paths short and non‑routed where possible. |
| Fibre Channel (SCSI‑FC) | Dedicated FC SAN; dual fabrics, zoning; not IP‑routed. | Yes. FC HBAs + FC switches. | 32 G and 64 G FC ports; FC standard up to 128 G FC. | Yes (standard in FC). | Lower latency and CPU than iSCSI, but SCSI stack still heavier than NVMe‑oF. | Stable, predictable; separate fabric and tooling; SCSI semantics cap scalability vs NVMe‑oF. |
| NVMe/TCP | Ethernet + TCP/IP; routable, but best practice is L2/VLAN‑local SAN (do not route NVMe/TCP data paths when possible). | No. Any standard NIC (≥10 GbE) and industry‑standard switch. | 25 G and 100 G, negotiable down to 10 Gb/s. | “Yes, if NIC supports it” – explicitly NIC/firmware‑dependent. | NVMe‑oF: up to ~35% lower latency and ~25% higher perf vs iSCSI in internal tests. More CPU than NVMe/RDMA or NVMe/FC. | Best iSCSI successor: reuses IP, no special HW, much better efficiency; tune MTU, LAG/MLAG, multipath; avoid routed designs for data. |
| NVMe/RDMA (NVMe/RoCEv2) | RDMA over Converged Ethernet; typically non‑routed, lossless fabric (PFC/ECN/DCB). RoCEv2 is IP‑routable but routing is rarely recommended due to lossless‑fabric complexity. | Yes. RDMA‑capable NICs + DCB/PFC/ECN‑capable switches. | 25 G and 100 G, negotiable down to 10 Gb/s. | Not generally supported; Pure/VMware: boot‑from‑SAN only via NVMe‑FC. | Microsecond‑class latency; lowest CPU of these options; Pure: NVMe/RoCE is top performer, ahead of NVMe‑FC and NVMe‑TCP. | Highest performance; best for ultra‑low latency and scale; requires carefully engineered lossless Ethernet and validated NICs/switches; usually keep L2 leaf–spine, non‑routed. |
| NVMe/FC | NVMe over Fibre Channel; same dual‑fabric FC design and zoning; non‑routed. | Yes. FC HBAs + FC switches (same stack as SCSI‑FC). | 16 G and 64 G FC (negotiable down to 8 G). FC roadmap to 128 G. | Yes – only NVMe‑oF boot‑from‑SAN method called out (HBA firmware‑dependent). | Lower latency / higher perf than SCSI‑FC; second only to NVMe/RoCE and ahead of NVMe/TCP on Pure. | Ideal for FC shops modernizing to NVMe while reusing fabric and process; still tied to FC ecosystem and bandwidth roadmap. |
In the following pages, you will find many FlashArray Block overview topics such as:
- Frequently Asked Questions.
- Best Practices for FlashArray Block.
- Compatibility and Support Information.
For overall compatibility information see the FlashArray Compatibility Matrix.