Maximum Sense Length for FC Tape and Media Changer

Rob Basham robbyb at us.ibm.com
Mon Apr 27 08:35:36 PDT 1998


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* Rob Basham <robbyb at us.ibm.com>
*

--Boundary=_0.0_=5030050010123089
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Dave,
Our drives are right at 96 bytes today on SCSI.  We could live with cut=
ting it
down to 128 bytes, but 96 bytes would be difficult to accept, leaving u=
s no
contingency at all.

On another topic (I am looking for some online discussion before our th=
e next
meeting):
I am concerned about error recovery done by the ULP on a port failure t=
hat
attempts to go over and use the alternate port.  I believe that there a=
re some
data integrity problems associated with alternate port error recovery. =
 What I
am worried about are conditions where the tape drive thinks it has succ=
essfully
sent error status to the host relative to block sequence errors and the=
 like.
Once a block sequence error is reported, the tape drive can be out in "=
old
data".  Read Position and Locate sequences that would be used by a ULP =
error
recovery in changing to an alternate port would be inadequate, at least=
 in
cases where class 2 service and FCP Confirm aren't supported.

The reason for this is that the tape drive, thinking that the block seq=
uence
error has been reported successfully, will not report it again up the a=
lternate
port path.  The host may never see the error if a port "goes down" just=
 as the
block sequence error is being reported.  If FCP Confirm or Class 2 are =
in
place, the drive can discern that the error wasn't reported successfull=
y and
report it on the alternate port.

So my question is this:
Is it agreed that for implementations that support alternate port error=

recovery, either FCP Confirm or Class 2 is required as things currently=
 stand?

I would also propose that a few bits could be added to the Read Positio=
n
command to close this hole and allow this type of recovery without thes=
e FC
mechanisms.  The state information bits would be something like the fol=
lowing:
1. Permanent Write Error on this load.
2. Permanent Read Error on this load.
3. Positioned Beyond End Of Data
4. Permanent Space Error on this load.
5. Permanent Locate Error on this load.

The bits, once set, would be cleared only on an unload (or possibly a r=
ewind).

Alternate port error recovery is new for tape drives, since so few have=
 them
today.  This will change with Fibre Channel, so I believe this discussi=
on needs
to take place.  The addition of these bits would help with those device=
s that
have dual Parallel SCSI ports as well (we have one such device in our p=
roduct
line).

Your thoughts?
Rob Basham
---------------------- Forwarded by Rob Basham/Tucson/IBM on 04/27/98 0=
8:11 AM
---------------------------


owner-t10 at Symbios.COM on 04/27/98 07:28:31 AM
Please respond to owner-t10 at Symbios.COM
To: t10 at Symbios.COM, fc at nsco.network.com
cc:
Subject: Maximum Sense Length for FC Tape and Media Changer


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* Dave Peterson <dap at nsco.network.com>
*
-----------------------------------------------------------------------=
---------
Howdy All,

To the FC tape and media changer vendors:

The FC-Tape profile currently states maximum
FCP_SNS_LEN (number of bytes) <=3D 255 for FC tape and
media changer devices.
While this value will work it would be nice to have a smaller value
(if possible). PLDA stated the FCP_SNS_LEN max value to be <=3D 96
for SCSI disk targets. So the question is will this also work for FC
tape and media changer devices?

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dave Peterson                     phone : 612-391-1008
Senior Engineer
StorageTek Network Systems Group  email: dap at network.com


-----------------------------------------------------------------------=
---------

*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com



=

--Boundary=_0.0_=5030050010123089
Content-Type: application/octet-stream; name=x
Content-Transfer-Encoding: base64

PEhUTUw+DQpIb3dkeSBBbGwsDQoNCjxQPlRvIHRoZSBGQyZuYnNwO3RhcGUgYW5kIG1lZGlhIGNo
YW5nZXIgdmVuZG9yczoNCg0KPFA+VGhlIEZDLVRhcGUgcHJvZmlsZSBjdXJyZW50bHkgc3RhdGVz
IG1heGltdW0NCjxCUj5GQ1BfU05TX0xFTiAobnVtYmVyIG9mIGJ5dGVzKSAmbHQ7PSAyNTUgZm9y
IEZDJm5ic3A7dGFwZSBhbmQNCjxCUj5tZWRpYSBjaGFuZ2VyIGRldmljZXMuDQo8QlI+V2hpbGUg
dGhpcyB2YWx1ZSB3aWxsIHdvcmsgaXQgd291bGQgYmUgbmljZSB0byBoYXZlIGEgc21hbGxlciB2
YWx1ZQ0KPEJSPihpZiBwb3NzaWJsZSkuIFBMREEmbmJzcDtzdGF0ZWQgdGhlIEZDUF9TTlNfTEVO
IG1heCB2YWx1ZSB0byBiZSAmbHQ7PQ0KOTYNCjxCUj5mb3IgU0NTSSBkaXNrIHRhcmdldHMuIFNv
IHRoZSBxdWVzdGlvbiBpcyB3aWxsIHRoaXMgYWxzbyB3b3JrIGZvciBGQw0KPEJSPnRhcGUgYW5k
IG1lZGlhIGNoYW5nZXIgZGV2aWNlcz8NCjxQUkU+LS0mbmJzcDsNCj09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCkRhdmUg
UGV0ZXJzb24mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgcGhvbmUgOiA2MTItMzkxLTEwMDgNClNlbmlvciBFbmdpbmVlciZuYnNw
Ow0KU3RvcmFnZVRlayBOZXR3b3JrIFN5c3RlbXMgR3JvdXAmbmJzcDsgZW1haWw6IGRhcEBuZXR3
b3JrLmNvbTwvUFJFPg0KJm5ic3A7PC9IVE1MPg0K

--Boundary=_0.0_=5030050010123089--
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com





More information about the T10 mailing list