RE: Status summary on multiple connections

[Robert Snively <rsnively@Brocade.COM>]

> 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. 

Sorry Joe,

You folks already have given up on ordering.  Your buffering structure is 
designed to perform lying writes.  You gather in a command, gather
in its data, post the completion and then pick up the next command.
No present day tape drive except a few of the highly specialized
Fibre Channel implementations allows ordered command queuing to be
invoked from the host adapter and no driver exploits it because it is
so rarely implemented.

It is only with Rob Basham's new tape command set proposal that you
are really going to get going full speed ahead into command queuing,
and that is because the ordering information is contained in the
command and the data can be pulled down as desired. 

The other major tape feature is copy management.  That works perfectly,
because the recipient or source of data is always a disk drive that
is being managed by a tape drive.  The tape can manage any re-ordering
necessary.

Bob