Maximum Sense Length for FC Tape and Media Changer

Dave Peterson dap at nsco.network.com
Tue Apr 28 12:09:24 PDT 1998


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

--------------3BB2564C42AF36E7DA55D346
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Rob Basham wrote:

> Dave,
> Our drives are right at 96 bytes today on SCSI.  We could live with cutting it
> down to 128 bytes, but 96 bytes would be difficult to accept, leaving us no
> contingency at all.
>
> On another topic (I am looking for some online discussion before our the next
> meeting):
> I am concerned about error recovery done by the ULP on a port failure that
> attempts to go over and use the alternate port.  I believe that there are some
> data integrity problems associated with alternate port error recovery.  What I
> am worried about are conditions where the tape drive thinks it has successfully
> 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 sequence
> error has been reported successfully, will not report it again up the alternate
> 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 successfully 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 don't believe it has been agreed to. I did talk about adding text
regardingdual-port issues at the last working group.
The above subject could be a candidate for inclusion.

>
>
> I would also propose that a few bits could be added to the Read Position
> command to close this hole and allow this type of recovery without these FC
> mechanisms.  The state information bits would be something like the following:
> 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 rewind).
>
> 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 discussion needs
> to take place.  The addition of these bits would help with those devices that
> have dual Parallel SCSI ports as well (we have one such device in our product
> line).
>
> Your thoughts?
> Rob Basham
> ---------------------- Forwarded by Rob Basham/Tucson/IBM on 04/27/98 08: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) <= 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 <= 96
> for SCSI disk targets. So the question is will this also work for FC
> tape and media changer devices?
>
> --
> ===================================================================
> 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
>
>   ------------------------------------------------------------------------
>
>            Name: x
>    x       Type: unspecified type (application/octet-stream)
>        Encoding: base64



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



--------------3BB2564C42AF36E7DA55D346
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit


 Rob Basham wrote: Dave, 
Our drives are right at 96 bytes today on SCSI.  We could live with cutting it 
down to 128 bytes, but 96 bytes would be difficult to accept, leaving us no 
contingency at all. On another topic (I am looking for some online discussion before our the next 
meeting): 
I am concerned about error recovery done by the ULP on a port failure that 
attempts to go over and use the alternate port.  I believe that there are some 
data integrity problems associated with alternate port error recovery.  What I 
am worried about are conditions where the tape drive thinks it has successfully 
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 sequence 
error has been reported successfully, will not report it again up the alternate 
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 successfully 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 don't believe it has been agreed to. I did talk about adding text regardingdual-port issues at the last working group. 
The above subject could be a candidate for inclusion.   I would also propose that a few bits could be added to the Read Position 
command to close this hole and allow this type of recovery without these FC 
mechanisms.  The state information bits would be something like the following: 
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 rewind). 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 discussion needs 
to take place.  The addition of these bits would help with those devices that 
have dual Parallel SCSI ports as well (we have one such device in our product 
line). Your thoughts? 
Rob Basham 
---------------------- Forwarded by Rob Basham/Tucson/IBM on 04/27/98 08: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) <= 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 <= 96 
for SCSI disk targets. So the question is will this also work for FC 
tape and media changer devices? -- 
=================================================================== 
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   ------------------------------------------------------------------------            Name: x 
   x       Type: unspecified type (application/octet-stream) 
       Encoding: base64   -- 
===================================================================
Dave Peterson                     phone : 612-391-1008
Senior Engineer 
StorageTek Network Systems Group  email: dap at network.com  

--------------3BB2564C42AF36E7DA55D346--

*
* 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