Support for Large Block Addresses in SSC

Paul Entzel Paul.Entzel at
Mon Feb 14 12:31:59 PST 2000

* From the T10 Reflector (t10 at, posted by:
* Paul Entzel <Paul.Entzel at>
Unfortunately, I will not be able to attend this week's meeting.  I have a
few comments on Paul Suhler's proposal T10/00-135r0 to be discussed there.
*	I would like to know where assumption number 4 came from, "Read and
write transfer lengths may be more than 2^24 bytes, but will be less than
2^32".  Many tape drives today don't even support the 16 MB limit.  Very
large blocks are difficult to manage, especially with respect to error
recovery.  The impact of this change is more far reaching than just the READ
and WRITE commands.  Since we don't want to write tapes in variable mode
that we can't read in fixed mode, the MODE SELECT / MODE SENSE Block
Descriptor will need to change to allow the large block sizes.  Also, the
READ BLOCK LIMITS command will also need to change to allow the reporting of
the larger size.
*	I would prefer the choice of 12 byte Command Descriptor Blocks for
the new commands over 16 byte commands.  Many of today's SCSI chips do not
support automatic processing of 16 byte commands.  This is less of an issue
with SPACE or LOCATE where time can be spared to process the CDB manually,
but if the committee chooses to define new READ and WRITE commands it will
require a new generation of SCSI chips.
*	As for the READ POSITION question, I prefer option 3.  We still need
a method of reporting the contents of the buffer following a write failure
or volume overflow.  The current Long form does not provide for this.
*	I strongly recommend that we not hold up the approval process of SSC
while we decide these issues.  We have waited long enough for this
specification.  Most of the other specifications are at level 2 already, and
some are working on even higher levels.

Thanks for listening,
Paul Entzel
Quantum, DSSG
(720) 406-5782

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

More information about the T10 mailing list