RE: iSCSI:flow control, acknowledgement, and a deterministic recovery

[Black_David@emc.com]

> > Immediate commands are "out of sequence" by definition - immediate
> > means deliver immediately without regard to CmdSN order.  Only the
> > target can do this, so I don't see any problem with relying on the
Target
> > to do so.
> 
> The commands that are NOW out of sequence are those commands bypassed by
the
> immediate command.  If this immediate command was Rewind, then a long list
> of write commands become invalid as a new tape is now needed for those
> operations.  You are expecting that the target to handle a long list of
> invalid commands made possible by the iSCSI sequencer.  Commands
invalidated
> by immediate commands become out of sequence commands.

And I still don't see a problem here.  Tapes have to have logic
to deal with a write issued when no tape is loaded - this situation
is yet another way to invoke that logic.  The target was asked
to execute the Rewind immediately, did so, and now processes the
writes in its new state of not having a tape loaded (presumably,
they all result in check conditions).  Even if we do something
clever in the iSCSI "sequencer", the same behavior can result if
the write commands have been delivered to SCSI and queued in SCSI.
I don't see the point of adding a new way (iSCSI rejects vs. SCSI
check conditions) for what's essentially the same set of errors
(tape was rewound, therefore can't be written) to manifest themselves.

If the Initiator didn't want this
behavior, it should have done something else, such as not
using immediate delivery for the Rewind, or sending
some suitable Task or Task Set Aborts.  

> I'll reserve further comment until Julian has made some progress in
> addressing these concerns.  I also suspect it is a mistake to allow
commands
> to remain trapped within the sequencer during emergency or abnormal events
> signified by the use of these immediate commands.

Resetting the sequencer probably involves a Lun or Target
Reset, which may be necessary in any case to clean up
from these sort of emergency or abnormal events.  Keep
in mind that SCSI Task Management is inherently
non-deterministic, and so asking for completely predictable
behavior in these sort of circumstances is just plain
unreasonable.

--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------