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.
