Scsi bridging is how stateful?

Pat LaVarre LAVARRE at
Tue Mar 12 15:10:41 PST 2002

* From the T10 Reflector (t10 at, posted by:
* "Pat LaVarre" <LAVARRE at>
[[[ I think here I'll try BC t10 at, since I see other people have chosen to reply to <sbp3 at,> without carrying forward the CC to t10 at ]]]

The bridging that interests me is the exclusive use of a device by one host.

I hear, for example, that two commodity desktop PC's, connected to one 1394 device, randomly choose which host gets to see the device - the other host does not.  So much for the theory of peer-to-peer: the practice is point-to-point.

Pat LaVarre

>>> Byan, Stephen 03/07/02 09:04AM >>>
* From the T10 Reflector (t10 at, posted by:
* "Byan, Stephen" <Stephen_Byan at>
Pat LaVarre [mailto:LAVARRE at] wrote:
> Seems to me, with Sbp-2, the bridge is stuck translating the 
> command set.  The
> bridge has to form a redundant opinion of how many bytes 
> should move which
> way, just so that it can check that is indeed what happens, 
> just so that it
> can report inappropriately nonzero residue as an error.

In general, I think bridging between different SCSI transports is almost
always inherently stateful, meaning that the bridge needs to do just what
you describe: interpret the command-set. 

Beside the issue you point out, SCSI also requires the logical unit to be
aware of how many initiators to which it is talking, and to maintain state
(such as allegiance state) for each intiator. There may be some combinations
of transports where this can be bridged statelessly, but in general I think
the bridge is stuck having to interpret commands.

Another reason for interpreting commands in a bridge might be to accomodate
the differences in flow-control between the transports. If you're bridging
fibre channel to a parallel scsi device, and the bridge runs out of BB
credits, it can't simply ask the parallel SCSI device to switch to commands
for an initiator for which the brdige has available credit. It's stuck, as
the SCSI target decides when to get off the bus. In this case, the bridge
wish to perform extensive internal buffering; for the bridge to accept data
in advance of the initiator it must be able to interpret the command in
order to proxy for the initiator.

In the restricted case where the bridged target supports a larger initiator
address space than the bridged-to transport, and the bridge punts on
flow-control issues, the bridge might be able to get away with only
maintaining the state of an initiator address translation table, and
maserading as the appropriate intitiator when talking to the device.

* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list