Stateless tape model

JoeBre at exabyte.com JoeBre at exabyte.com
Fri Aug 25 14:45:32 PDT 2000


* From the T10 Reflector (t10 at t10.org), posted by:
* JoeBre at Exabyte.COM
*
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C00EDD.CB1B0200
Content-Type: text/plain; charset="iso-8859-1"

A couple of comments: 

(4 or 6?) byte absolute LBAs should be 8 byte: 
There has been a fair amount to discussion recently about the
insufficiency of 2^32 LB's. All absolute LBA's should be 8 bytes. You
have them listed as (4 or 6?) bytes. A recent proposal by Paul Suhler of
Seagate has requested 8 bytes for these absolute LBA's. I believe there
was fairly wide consensus that this was desireable. See
T10/00-135r0.pdf. This proposal also extends relative LB counts
(transfer lengths) to 4 bytes.

3.2 - READ(10): 
Some applications use SetMark as a mark that is heirarchically superior
to FileMark. I would suggest that the sentence: 
"Another difference from the READ(6) command would be that if a filemark
is encountered, it is not traversed." 
be changed to: 
"Another difference from the READ(6) command would be that if a filemark
or setmark is encountered, it is not traversed."

Although we do not support READ REVERSE, I would imagine that symmetry
arguments would suggest that the same sentence be provided in 3.3

3.5 - SPACE(10) - PFT bit: 
Should be extended to SetMarks as well. If you ask, I'll develop text
for this. 
Then again, maybe a better approach is to eliminate SPACE, and define a
new LOCATE that will optionally accept FileMark identifiers or SetMark
identifiers, as well as LBA's. Actually, the latter sounds better, as
SPACE has always been relative, and LOCATE has always been absolute. How
'bout I rescind my offer to develop text for SPACE, and replace it with
an offer to develop text for LOCATE?

4 - Unresolved Issues: 
a) policy when LBA requested is not the current position? 
The first I heard of this idea, I thought people were clamoring for
Random-Access Tape. You can imagine my relief to find that this is not
the case. Accordingly, we need to make an explicit statement in the SCSI
Tape Device Model indicating that it is still a Stream Device.
Otherwise, someone, some day, will take us poor tape guys to task for
not being able to randomly write to our device. As far as CHECK
CONDITION for LBA mismatch on read only or on both read and write, I'll
defer to the wisdom of the HBA and System people -- I can do it either
way.

b) mode settings: 
I imagine we'll find some. Perhaps we should define a new Device Type
identifier for Stateless Stream Device. This would make these new CDBs
mandatory (or at least the new CDBs that are analogs of current
mandatory Tape CDBs), and make the old CDBs prohibited. We can let the
initiator specify the Device Type, much as an initiator can specify that
an MO disk act like a DASD.

c) partition number 
I hate to open this can of worms, because I know that not all tapes
support partitions. However, to truly be stateless, each CDB will need
to specify the partition. Currently, changing partitions is handled by a
LOCATE CDB. If this CDB gets lost, a subsequent WRITE could corrupt the
media. (Did I not mention that we _do_ support partitions?). Each CDB
will need to be augmented by partition number.

All for now... 
Joe Breher 
Exabyte Corp 

----------------------- 
VOTE! 

> -----Original Message----- 
> From: Rob Basham/Tucson/IBM [ mailto:robbyb at us.ibm.com
 ] 
> Sent: Thursday, August 24, 2000 9:56 AM 
> To: t10 at t10.org 
> Subject: Explicit State Command Set Proposal 00-318r0 Available 
> 
> 
> * From the T10 Reflector (t10 at t10.org), posted by: 
> * "Rob Basham/Tucson/IBM" <robbyb at us.ibm.com> 
> * 
> Document 00-318r0, a proposal  for an explicit state command 
> set for tapes 
> is available. 
> Regards, 
> Rob Basham 
> IBM Tucson 
> 
> * 
> * For T10 Reflector information, send a message with 
> * 'info t10' (no quotes) in the message body to majordomo at t10.org 
> 


------_=_NextPart_001_01C00EDD.CB1B0200
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: Quoted-Printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">

Stateless tape model A couple of comments: (4 or 6?) byte absolute LBAs should be 8 byte: 
There has been a fair amount to discussion recently = about the insufficiency of 2^32 LB's. All absolute LBA's should be 8 = bytes. You have them listed as (4 or 6?) bytes. A recent proposal by = Paul Suhler of Seagate has requested 8 bytes for these absolute LBA's. = I believe there was fairly wide consensus that this was desireable. See = T10/00-135r0.pdf. This proposal also extends relative LB counts = (transfer lengths) to 4 bytes. 3.2 - READ(10): 
Some applications use SetMark as a mark that is = heirarchically superior to FileMark. I would suggest that the = sentence: 
;Another difference from the READ(6) command = would be that if a filemark is encountered, it is not traversed.; = 
be changed to: 
;Another difference from the READ(6) command = would be that if a filemark or setmark is encountered, it is not = traversed.; Although we do not support READ REVERSE, I would = imagine that symmetry arguments would suggest that the same sentence be = provided in 3.3 3.5 - SPACE(10) - PFT bit: 
Should be extended to SetMarks as well. If you ask, = I'll develop text for this. 
Then again, maybe a better approach is to eliminate = SPACE, and define a new LOCATE that will optionally accept FileMark = identifiers or SetMark identifiers, as well as LBA's. Actually, the = latter sounds better, as SPACE has always been relative, and LOCATE has = always been absolute. How 'bout I rescind my offer to develop text for = SPACE, and replace it with an offer to develop text for = LOCATE? 4 - Unresolved Issues: 
a) policy when LBA requested is not the current = position? 
The first I heard of this idea, I thought people = were clamoring for Random-Access Tape. You can imagine my relief to = find that this is not the case. Accordingly, we need to make an = explicit statement in the SCSI Tape Device Model indicating that it is = still a Stream Device. Otherwise, someone, some day, will take us poor = tape guys to task for not being able to randomly write to our device. = As far as CHECK CONDITION for LBA mismatch on read only or on both read = and write, I'll defer to the wisdom of the HBA and System people -- I = can do it either way. b) mode settings: 
I imagine we'll find some. Perhaps we should define = a new Device Type identifier for Stateless Stream Device. This would = make these new CDBs mandatory (or at least the new CDBs that are = analogs of current mandatory Tape CDBs), and make the old CDBs = prohibited. We can let the initiator specify the Device Type, much as = an initiator can specify that an MO disk act like a DASD. c) partition number 
I hate to open this can of worms, because I know = that not all tapes support partitions. However, to truly be stateless, = each CDB will need to specify the partition. Currently, changing = partitions is handled by a LOCATE CDB. If this CDB gets lost, a = subsequent WRITE could corrupt the media. (Did I not mention that we = _do_ support partitions?). Each CDB will need to be augmented by = partition number. All for now... 
Joe Breher 
Exabyte Corp ----------------------- 
VOTE! > -----Original Message----- 
> From: Rob Basham/Tucson/IBM [mailto:robbyb at us.ibm.com] 
> Sent: Thursday, August 24, 2000 9:56 AM 
> To: t10 at t10.org 
> Subject: Explicit State Command Set Proposal = 00-318r0 Available 
> 
> 
> * From the T10 Reflector (t10 at t10.org), posted = by: 
> * ;Rob Basham/Tucson/IBM; = <robbyb at us.ibm.com> 
> * 
> Document 00-318r0, a proposal  for an = explicit state command 
> set for tapes 
> is available. 
> Regards, 
> Rob Basham 
> IBM Tucson 
> 
> * 
> * For T10 Reflector information, send a message = with 
> * 'info t10' (no quotes) in the message body to = majordomo at t10.org 
> 
------_=_NextPart_001_01C00EDD.CB1B0200--




More information about the T10 mailing list