T
p 103
6.1.1 Usage of Retry and 6.7 SCSI Timeouts: the semantics of Retry
remain
broken rendering it useless for tape operation. SCSI level error
detection
and recovery is the preferred mechanism. Refer to previous emails
sent via
the IPS reflector regarding this matter.
+++ Dave. The retry scheme for connection recovery implies that the
other two levels are there.
So even
if I would agree with your POW (which I am not) for practical reasons the
mechanisms described
will have to
stay.
+++
dap: again, without a standardized method for
error detection (see the options I listed) to determine when the
retry may be performed, the retry functionality is
broke/useless/inconsistent for tape applications. This is not an
implementation detail as some suggest. This must be consistent across vendor
implementations for a tape application to work
consistently.
T
p 128
8.6 Considerations for State-dependent devices: last
paragraph:
don't agree with the statement that error recovery at the iSCSI
level
(specifically Retry in its current state) is advisable. Retry at the
SCSI
level is feasible and is not difficult (i.e., READ POSITION and
LOCATE
commands). This paragraph should be removed.
+++ that is not what we repeatedly hear. I will
however make a "softer" statement. +++
dap:
I don't know who is feeding you this information. READ POSITION is and has
been mandatory to implement for tape devices for quite a while now.
Additionally I'm on the verge of making LOCATE mandatory (in reality if READ
POSITION is implemented, so is LOCATE). Any backup app/application
client worth anything uses READ POSITION (and LOCATE). I have a major
problem with any text that suggests otherwise. The use of READ POSITION and
LOCATE mitigates the need for retry (and most error recovery) at the transport
level, and this is where I want to go. Retry at the application level
simply must not be performed without first:
1.
determine the position of the device using READ POSTITION,
then
2.
(re)position the device if
neccessary, then
3.
continue
This
is not difficult, provided READ POSITION/LOCATE are
supported.
If
the offending paragraph is indeed targeted for legacy device support, it
certainly does not say that. In reality, todays inplementations use
READ POSITION/LOCATE extensively and (legacy) devices that do not support
these commands are very rare for this type of tape
application/environment.
I
expect that a legacy tape device will be front-ended by a bridge device
(i.e., I don't expect to see a native-iSCSI legacy tape device). This legacy
tape device will not support the desirable functionality (such as FCP-2 error
detection and recovery) thus placing a burden on a bridge device if the
desired goal is to be achieved.
Furthermore, the legacy devices will generally be of the
Parallel SCSI variety, not FCP. The FCP-x tape devices I know of each support
READ POSITION/LOCATE.
The
offending paragraph (draft 15):
"For many of those state changing commands the execution model also
assumes that the command is executed exactly
once. For those commands a retry at SCSI level
is not feasible or very difficult and error
recovery at iSCSI level is advisable."
must
be removed.
Note: The connection reassignment capability does provide use
for tape applications, e.g, will hopefully keep the application running. I
have no problem using the retry functionality in this
context.
T
p 214
11.11 BidiInitialR2T: this text key
provides no value and needs to
be removed. InitialR2T should be used for
both uni and bidirectional
commands. In addition, if BidiInitialR2T were to
be used, it will not
function via an iSCSI-FCP gateway.
+++ A
gateway can easily map the keys. We don't know enough to decide off-hand to
remove it.
But I am still
listening.
+++
dap: There is no reason to have a different
key to indicate whether or not an R2T will be used for bidi commands.
InitialR2T works just fine for both. FCP uses just one
parameter (i.e., write FCP_XFER_RDY disabled) for both and all is
well. What more can I say, other than remove the
key.
