A Nexus, in the world of Storage Networking is a unique identifier. It identifies the components involved in a command or sequence of commands. It is normally made up of the following parts:
Initiator (I), Target (T), LUN (L), and Queue Tag (Q). This is an ITLQ nexus.
Establishing the Nexus
In parallel SCSI (and most storage systems), everything starts on the host side of the system. When a host wants move some data (do a READ or WRITE) it will need to know that a storage device exists, and then build and send a command to it. But there is another SCSI protocol that takes place to connect and issue the command. That protocol is below.
- Arbitration - initiator ID is placed on the bus (usually #7).
- Selection - target ID is place on the bus and target takes control. At this point, an I_T nexus exists.
- Message(s) – target asks for bytes to identify the LUN and Q-Tag (if needed). This is where the full I_T_L_Q nexus is established.
- Command - CDB is sent to the device, which processes the command and controls the flow.
- Data - this is the data movement phase (IN for READ, OUT for WRITE).
- Status - information is sent back to the host (command worked or had an error).
- Message - this tell the host that the command is done.
Once the command is finished, the nexus is “released” and can be used again. This is because the nexus is only needed while the command is in progress.
Disconnect and Reconnect
The protocol shown above shows a single connection, where everything is done during that connection. But where the nexus really comes into play is when there is a disconnect and reconnect after the command had been issued. This is one of the biggest benefits of “networked” storage. While the storage devices are disconnected, the host can connect to another device and start a different command with it.
The important part is that while a command is still in process (no status yet), the nexus remains and is known to the host. The storage device also can do “slow stuff” while disconnect, such as moving the heads, spinning the platters, that kind of thing. When the device has the data ready (READ), or has resources to accept more data (WRITE), then it will use the same nexus values (I_T_L_Q) and will reconnect to the original host to continue the command sequence. This can happen multiple times for a single command, and the nexus remains until the command is complete.