Re: Status summary on multiple connections

[Matt Wakeley <matt_wakeley@agilent.com>]

David Robinson wrote:

> > I am left with the following impression as to what was indicated here:
> > - In general, command ordering is not relevant
> > - If the initiator filesystem detects an ordering dependency, it will wait
> > until outstanding commands are complete before issuing the dependant
> > command.
> >
> > This may be a reasonable means of operation for the disk world. It is
> > woefully inadequate for the tape world, as follows:
> > - In general, command ordering is crucial - out of order command processing
> > will lead to data corruption.
> > - This would require the initiator backup application to block on completion
> > of every single write command of a backup operation before issuing the next
> > command.
> >
> > If this blocking were performed, both the throughput and capacity of a tape
> > device/media would be negatively impacted by an order of magnitude or more.
> > This would occur even assuming an instantaneous transport.
>
> I am hearing different stories on the issue of ordering.  One side
> is pushing hard for techniques that will allow out of order
> execution using various RDMA techniques. This clearly states for
> a certain class of devices (e.g. tapes) ordering is crucial.
> I thought this problem was already solved at the SCSI layer
> through the use of ordered commands which in general are not used
> for disks but always used for tapes?

The ordered commands option in SCSI indicates that the commands shall be executed
in order.  The only way SCSI knows of the "orderness" of the commands is if
they're received in order.

> Since FC will reorder this has to be a solved problem.

It's solved in the FC layer, not SCSI.  FC provides for "command numbering" such
that the receiver of the commands verifies the orderness of the commands by
sorting them based on the command numbers before delivering them to SCSI.

> Would not an initiator talking to a tape target simply set the ordering flag?

Nope.  The transport layer has to guarantee that the commands are delivered to
SCSI in the same order that the transport layer received the commands from SCSI.


> Lastly, for a TCP based connection ordering can easily be made a
> non-issue, simply don't try to process segments out of order.

The issue is not commands on a single TCP connection.  The issue is keeping
commands in order that were issued on multiple connections (making up a single
session).  Ordering across TCP connections is not guaranteed, only within a TCP
connection.


> I will defer to a transport expert, but I believe processing
> TCP segments by an application out of order might cause problems.
> In particular since the out of order segment is not ACKed until
> after the missing segments arrive, they can be retransmitted
> multiple times.  SACK helps this but does not guarentee that
> segments will not be retransmitted. So to process out of order
> segments the application must maintain a list of which segments
> have been processed as well, yuck!
>
>         -David
>

-Matt