Re: iSCSI: remove recovery from transport-layer connection failur e(?)

[Stephen Bailey <steph@cs.uchicago.edu>]

> If, on the other hand, iSCSI is not to be SAM/SAM-2 compliant...

OK, I'm an idiot.  Where in SAM-2 does it say that this behavior is
required?

> A mature tape drive, coupled with a mature backup application, is unlikely
> to run off the end or get eaten.

I guess I misspoke.  Running off the end in this case means `filling
up'.  Amanda is a mature backup application, it writes on the tape in
the drive until it's full.  It reminds the operator to change the
tape, but it doesn't require it.

> I guess 'relatively high frequency' must be qualified.

I was not making the claim that `tape is unreliable'; only that it's
subject to more and more frequently occuring nonnominal phenomena than
winchester disks.  The same is true of other changable/ejectable
media.  For example, your own (Exabyte 8mm) tape drives (dunno if they
still do this, but they certainly did once upon a time), refuse to
operate if they haven't been cleaned within some particular interval.

> The problem area that I foresee is where commands get lost in
> transmission.

This will not happen in iSCSI.  Unlike ||SCSI and FCP, the underlying
iSCSI transport is `reliable'.  What that means is that if the command
(or response, or data) does not get through in iSCSI, there is no
immediate action that the ULP (SCSI) can take to rectify the
situation.  The path between the two endpoint IP addresses is dead.
If the ULP choses to change one or the other endpoint IP addresses,
there may be a new path, but that's a different kettle of fish.

In fact, it IS the kettle of fish that started this discussion, but as
David pointed out in 'iSCSI sessions: Let's try again', this is an
enhancement over what other SCSI transports offer.  A message a few
months ago pointed out that FCP-2 does not provide this capability,
although it has been cursorily discussed.

Steph