Re: Status summary on multiple connections

[Matt Wakeley <matt_wakeley@agilent.com>]

JoeBre@exabyte.com wrote:

> Much good discussion on SCSI device level flow control snipped....
>
> > From: Robert Snively <rsnively@Brocade.COM>
> > To: "'David Robinson'" <David.Robinson@EBay.Sun.COM>, Robert Snively
> > <rsnively@Brocade.COM>
> > Subject: RE: Status summary on multiple connections
> > Date: Thu, 28 Sep 2000 09:36:50 -0700
>
> ...
>
> > are again available.  Note that there is a possibility that commands
> > that are inflight and have ordering constraints may be accepted out of
> > order, a question that has caused lots of agonizing, but is apparently
> > reasonably well managed by most file systems today by the selective
> > use of ordering only for blocking boundaries of a particular logical
> > stream of commands.
>
> 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:

>From what I understand, it's woefully inadequate for disk mirroring
applications as well.

>
>
> - 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.
>
> Joe Breher
> Exabyte Corp