Block Storage over a Network¶
Present remote storage to a host as a block device by carrying block I/O requests, data, and completion status across a network.
Core Idea¶
Block storage over a network is an access arrangement in which a host sees remote capacity through a block-device interface and its I/O requests reach a target across a network. The host addresses blocks rather than asking a server for named files; the target fulfills requests against backing storage and returns data or completion status. The common identity is the host-visible block boundary plus remote request/response path, not one disk command set or transport.[1][2][3]
iSCSI carries SCSI commands over TCP between an initiator and target. Linux Network Block Device (NBD) exposes a remote server-backed device such as /dev/nb0 and sends its block requests over TCP. NVMe over Fabrics extends NVMe commands across specified fabrics. Those protocols instantiate different command and addressing choices; the broad abstraction must not inherit ATA over Ethernet's raw-layer-2 or no-IP constraints from the Wikipedia starting page.[1][2][3]
Structural Signature¶
Sig role-phrases: host-visible block endpoint → initiator request path → network transport → remote target/backing capacity → data or completion status.
- Host-visible block endpoint: the client storage stack sees an addressable block device, not merely a remote named-file API.[2]
- Initiator request path: host I/O becomes a protocol request with enough identity/context for completion; iSCSI carries SCSI commands, whereas NBD uses its own block-request mechanism.[1][2]
- Network transport: separated endpoints exchange request/data/status over TCP or another permitted fabric. No one fabric or naming scheme is universal.[1][3]
- Target and backing resource: the remote side fulfills the block operation and returns its result. A packet flow without a usable backing block resource is not this storage service.[1][2]
Discovery, encryption, redundancy and coherent multi-host writes are important system-design concerns but not constitutive guarantees of this access pattern.
What It Is Not¶
It is not network file sharing. Linux's NBD documentation explicitly contrasts its block device with NFS: the client can put a filesystem on the remote block device, whereas a file service provides server-level named-file operations. That ability is not a requirement that every host create its own filesystem, nor does it confer safe shared write access by itself.[2]
It is not synonymous with one protocol. Native-command encapsulation is true of iSCSI's SCSI-over-TCP design and NVMe-oF's NVMe command extension, but NBD's request format is different. Raw Ethernet, routability, low latency, security or a particular address scheme do not follow from the broad identity.[1][2][3]
Scope of Application¶
RFC 7143 specifies iSCSI, which maps initiator/target SCSI concepts into a TCP transport, including command, data and response exchanges. That is a protocol-defined remote block-storage path using SCSI semantics.[1]
The Linux NBD implementation presents remote server-backed capacity as a client block device. On a read of /dev/nb0, the client sends a request over TCP and receives data from the server. NVMe-oF supplies a third comparison: NVM Express describes NVMe commands moving between host and remote SSD/system over network fabrics. Its linked 1.x page is explicitly historical; current NVMe 2.x content is elsewhere, so we use it only to establish the variant family, not current conformance detail.[2][3]
Clarity¶
Ask which interface the client sees. A file-share mount exposes files and server-side file semantics; NBD exposes a block node on which the client may place a filesystem. The object of host I/O is a block address or device operation, even if another software layer later offers files.[2]
Also ask what crosses the wire. In iSCSI it is specified SCSI command/data/status traffic over TCP. In NBD the kernel documentation describes block requests to a server, not unchanged SCSI or ATA commands. Treating every network block system as command-tunneling of one legacy disk protocol would wrongly exclude a real instance.[1][2]
Manages Complexity¶
The abstraction separates the host's stable block-I/O interface from protocol-specific transport. That lets one compare SCSI/TCP, NBD/TCP and NVMe/fabric systems by the same role map while still asking different questions about command semantics, names, failure recovery and performance. It prevents every network storage deployment from being flattened into either “remote disk” or “file share.”[1][2][3]
The separation also reveals an obligation: a local-looking block endpoint masks a remote failure domain. The transport or target can fail independently of the host; availability, timeout/retry and multi-host coordination require protocol or deployment design beyond the block-interface label.[1][2]
Abstract Reasoning¶
For a candidate system, trace one host block read. Identify the device interface, initiator request, network transfer, target-backed read and returned data/status. If the host instead asks the server to open a named file, the classification changes. If the request never leaves the host for a network-separated target, the storage is not over a network.[1][2]
Then bound inferences. From the block interface alone one may infer that host-side filesystem software can operate over the exposed device in an NBD-like case. One may not infer cache coherence between two hosts, protection against transport failure or a guaranteed latency class. Those depend on additional layers and protocol/deployment choices; the cited standards do not make them universal guarantees.[2][3]
Knowledge Transfer¶
iSCSI and NBD share host block endpoint / initiator / network / target / completion. iSCSI preserves SCSI command semantics across TCP; Linux NBD sends its own block requests over TCP to a userspace server. The common structure transfers without claiming identical wire formats or naming systems.[1][2]
NVMe-oF confirms that changing command family and fabric can retain the high-level role map, but its performance and transport details are not inherited by iSCSI or NBD. The official NVMe page itself labels its original specification historical and points readers to current base/transport specifications.[3]
Examples¶
iSCSI logical storage. Mapped back: host endpoint = SCSI logical storage exposed through an initiator; request path = iSCSI command/data exchange; network = TCP; target = SCSI target returning data and status. RFC 7143 defines these roles and their interactions. No raw-Ethernet-only rule is inferred.[1]
Linux NBD device. Mapped back: host endpoint = /dev/nb0; request path = NBD client block read/write request; network = TCP in the cited implementation; target = remote NBD server backed by storage and returning read data. The client can use a filesystem atop the device, distinguishing this from NFS without promising multi-host coherence.[2]
Structural Tensions¶
Local-like interface versus remote failure. A block device lets existing host software issue familiar operations, but remote transport and target failure can interrupt completion. Treating it as purely local eases integration at the cost of hiding failure modes; exposing every network concern to applications reduces that illusion but complicates use. Diagnostic: Where does completion originate, and what happens when the path fails?[1][2]
Block flexibility versus shared-write coordination. Client-side file systems and raw block tools gain flexibility, yet a block protocol does not itself coordinate concurrent filesystem metadata updates across hosts. Central file service can provide higher-level coordination but changes the interface. Diagnostic: Which layer owns filesystem state and enforces safe multi-host writes?[2]
General architecture versus protocol detail. A broad role map unites iSCSI, NBD and NVMe-oF, but pretending they share one command set erases real interoperability and error-semantic differences. Over-specifying one protocol excludes others; under-specifying the block-device interface admits unrelated file services. Diagnostic: What precisely is common at the host boundary, and what remains transport-specific?[1][2][3]
Structural–Framed Character¶
Evaluative weight. Remote block access is an architecture, not inherently better than local disks or file shares; deployment goals govern the trade. Human-practice dependence. Engineers select block protocols, targets and failure policies, but the observable request/response structure can be tested independent of their preferred product.[1][2]
Institutional origin. IETF, Linux and NVM Express standardize distinct instances; no one standards body defines the whole pattern. Vocabulary travel. “Block device,” “initiator” and “target” carry precise storage meanings across several protocols; calling a remote document folder a block device merely imports vocabulary.[1][2][3]
Import versus recognition. Recognize a new instance by its host-visible block endpoint and network target exchange, not by branding as SAN or cloud storage. A remote file API fails the literal test even if it stores bytes on disks. Its character: predominantly structural within computer storage, with system-design choices and operational costs surrounding the core.[2]
Structural Core vs. Domain Accent¶
Portable skeleton. A general remote-service proxy pattern may be a future-prime question, but no checked live prime was shown to be the necessary genus of this block architecture. Live Data Storage is a broad recording activity, not a system that exposes a network-backed block endpoint; Cooperative Storage Cloud fragments data for distribution and is not coextensive. The proposed placement is therefore honestly unparented, not a forced lexical relation.[2]
Domain-bound mechanism. A host block request is represented for transport, fulfilled by a remote target and returned as data/status so the host storage stack experiences a block device. iSCSI, NBD and NVMe-oF differ in command vocabulary and transport while preserving that boundary. The architecture is about block-addressed I/O, not generic remote access.[1][2][3]
Why not prime. Blocks, storage devices, initiators, targets and network request completion are computer-system commitments. A person receiving a remote document or an organization delegating a task has a loose remote-service analogy but lacks the literal block interface. The broader proxy skeleton might travel; Block Storage over a Network remains domain-specific.
Instantiates / Related Primes¶
No canonical or staged parent is asserted. The node remains provisionally unparented because current live generic storage and proxy nodes do not supply the block-device genus. iSCSI, Linux NBD and NVMe-oF are protocol instances or neighbors, not interchangeable aliases.[1][2][3]
Neighborhood in Abstraction Space¶
Block Storage over a Network sits in a sparse region of the domain-specific corpus (67th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.
Family — Network Security Vulnerabilities & Trust (26 abstractions)
Nearest neighbors
- Unix Domain Socket — 0.87
- Peer-to-Peer Architecture — 0.84
- Cache-Only Memory Architecture — 0.83
- Network Protocol — 0.83
- Position-Independent Code — 0.83
Computed from structural-signature embeddings · 2026-10-08
Not to Be Confused With¶
ATA over Ethernet is one narrower raw-Ethernet command protocol and was the Wikipedia seed source, not the definition of this generalized identity. iSCSI and NVMe-oF are other command-family instances. NBD shows that unchanged native SCSI/ATA/NVMe commands are not universal. NFS/SMB file service exposes file operations rather than a client block device. Shared filesystem safety needs separate coordination guarantees.[1][2][3]
References¶
[1] M. Chadalapaka, J. Satran, K. Meth and D. Black, RFC 7143, Internet Small Computer System Interface (iSCSI) Protocol (Consolidated) (IETF, April 2014), abstract and §§4.1–4.2, 4.6. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o ↩p ↩q ↩r ↩s ↩t
[2] Linux kernel documentation, “Network Block Device (TCP version),” Overview. This directly distinguishes NBD block access from NFS file access. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o ↩p ↩q ↩r ↩s ↩t ↩u ↩v ↩w ↩x ↩y ↩z
[3] NVM Express, “NVMe over Fabrics (oF) Specification (historical reference only),” historical-reference description. The page directs current NVMe 2.x readers to newer base/transport specifications. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m