Comments So Far on MAM Proposal

JERMAN,STEVE (HP-Boise,ex1) steve_jerman at am.exch.hp.com
Thu Oct 28 16:06:35 PDT 1999


* From the T10 Reflector (t10 at t10.org), posted by:
* "JERMAN,STEVE (HP-Boise,ex1)" <steve_jerman at am.exch.hp.com>
*
The follow list all the comments I have received so far. My responses are
after the comments. I will continue to collect comments and review the
proposal after next weeks meeting. Thanks for all the comments. They help
alot.

Regards
Steve

[Keith Wolfe - Intellistor]
1) Are READ ATTRIBUTE and WRITE ATTRIBUTE optional commands?
--> As far as the SCSI spec is concerned they would be optional. 

2) What was the motivation to drop the proposal to support MAM access via
Log Sense and Log Select?
--> Dal Allen suggesting that there may be general uses for this
functionality, problems with library access (no write capability with Read
Element Status) and some issues with parameter sizes.

3) What is the state of the Inquiry Auxiliary Memory page 84h?
--> We decided it wasn't necessary with the new commands. It also
complicated things alot.

4) Instead of having one ASC/ASCQ indicating auxiliary memory is not
accessible, please consider having two different ASC/ASCQ's so that there is
a differentiation between auxiliary memory that is not present and bad
auxiliary memory:
a) ASC/ASCQ 'AUXILIARY MEMORY NOT ACCESSIBLE' (e.g. a cartridge is not
installed in the tape drive)
b) ASC/ASCQ 'BAD AUXILIARY MEMORY' (e.g. a cartridge is installed in the
tape drive, but auxiliary memory read/write accesses have failed).
--> I have had several comments around this subject. Sounds like a good
idea.

5) Page 3, paragraph 6: Is the 'INVALID FIELD IN ATTRIBUTE LIST' ASC/ASCQ
new? Why not call the Attribute List Length field the Parameter List Length
and use the 'INVALID FIELD IN PARAMETER LIST' ASC/ASCQ?

--> Bad use of search and replace. I will correct.

6) Page 3, paragraph 1 and page 5, paragraph 1: Since the WRITE ATTRIBUTE
and READ ATTRIBUTE commands use "elements", it would be helpful to
incorporate a definition and list of elements in the SCSI command set
document in which WRITE ATTRIBUTE and READ ATTRIBUTE reside (e.g. SPC-2?)
instead of referring to a device-specific command set (e.g. SMC).

--> I will need some advice here, my understanding is that things should not
be defined in multiple places. 

7) Page 4, paragraph 3: Is the 'ATTRIBUTE LIST LENGTH ERROR' ASC/ASCQ new?
Why not use 'PARAMETER LIST LENGTH ERROR'?

--> S&R issue again

8) Page 5, paragraph 7: What if the available space as specified by the READ
ATTRIBUTE Allocation Length can not be filled  with "complete" attributes,
i.e. a truncated attribute is needed to fill the Allocation Length?

See page 5:
'The ALLOCATION LENGTH field in the CDB indicates how much space has been
reserved for the
returned attribute list. If the length is not sufficient to contain the
entire attribute list, complete attributes
will be returned until the available space has been filled. This shall not
be considered an error.'

9) Page 5, paragraph 8: Why not define a new Mode Sense page to get this
information instead of using the 'DISCOVERY KEY' mechanism in the READ
ATTRIBUTE command? The Mode page could be similar to Mode page 1Dh (Element
Address Assignment  Parameters) as supported for a Medium Changer device,
with the addition of Volume Numbers and Partition Numbers support.

--> This might be possible. Only issues are  (1) it would be nice to keep
things self contained, (2) the Discovery Key supports a tree heirarchy so if
the use of these commands expands the Discovery mechanism does not need to
change. (3) See Dana Lanes comment below.

10) Page 6, last paragraph: If one device server in a target supports the
SSC command set and a second device server in the same target supports the
SMC command set, then I presume the element addresses can differ between the
two device servers? 

For example, the SSC based device server would have access to at most only
one Storage Element at any given time, i.e the
cartridge currently loaded, but the SMC based device server would most
likely have access to many Storage Elements.

--> Yes, the idea is if a library supports the commands, the same Element
Addresses will be used. If a tape is part of the same LUN, I think that that
would be a 'Data Transfer' element.

11) Page 7, last paragraph: shouldn't 'WRITE ATTRIBUTE' be 'READ ATTRIBUTE'?

--> Oops

12) Page 8, paragraph 5: If the READ ONLY bit is one, the attribute is
read-only? If the READ ONLY bit is zero, the attribute is read-write?

--> Yes, I'll clarify

13) Page 8, paragraph 7: The description of clearing attributes is a little
confusing. I have a couple of questions with regard to clearing attributes:

--> I need to clarify this a bit.

a) Is it possible to clear multiple attributes at one time even though only
one Attribute ID is sent with an Attribute Value of zero using the WRITE
ATTRIBUTE command?

--> I'm not sure what you mean. You can send multiple zero length attributes
with the WRITE ATTRIBUTE command. They will all be cleared. Only the
parameters specified in the Parameter List will be cleared.

b) Could a mechanism be implemented in WRITE ATTRIBUTE so that all host
changeable attributes can be cleared without sending any attribute data
(i.e. something like PCR in Log Select)?

--> Doesn't (a) handle it OK?

c) Could a mechanism be implemented such that an attribute could be cleared
and still be reported in response to a subsequent READ ATTRIBUTE command?

--> I need to clarify this. My wording is suffering from multiple revisions.
On reflection, only 'host' parameters need dissapear when cleared. Device
and Media parameters can remain in existance with zero length or 0 contents.
Again on reflection, some parameters may not be resetable. Do I need to
indicate that?

14) Page 8, byte 1 in example at bottom of page: Byte 1 should be 03h, not
01h.

--> That table has been wrong in virtually every version I have done. I'll
correct it again.

15) Section 8.X.1, pages 9-15: Steve, many months ago I received a paper you
authored titled "Mapping of Media Auxiliary Memory Access Commands to
LTO-CM". The latest version I have is version 2, dated Feb. 3, 1999 which
contained a mapping of a subset of LTO-CM parameters. If you have a later
version, would you please send me a copy or let me know where I can access
it online?

I believe this is a good opportunity to be sure the LTO-CM parameters are
fairly/completely represented in the Media  Auxiliary Memory Attribute Data
for the READ ATTRIBUTE and WRITE ATTRIBUTE commands. It would be nice to
have all of the LTO-CM parameters supported by the different LTO vendors in
the same way via READ ATTRIBUTE and WRITE ATTRIBUTE to promote
data/cartridge interchange capabilities. Is your intent for LTO-CM
parameters that are not represented by Attributes defined for READ ATTRIBUTE
and WRITE ATTRIBUTE, to be defined in a vendor unique way in the vendor
unique sections of the Attribute data?
--> Addressed in separate email

16) Page 9: Is the Load Count attribute (ID 0003h) the same as bytes 48-51
in the Media Usage History Information?

--> Yes

17) Page 12, MEDIA TYPE: Has the density codes for LTO Ultrium been ratified
by ANSI? Are they 40h, 41h, 42h, and 43h for LTO Ultrium generation 1, 2, 3,
and 4 respectively?

--> Addressed in separate email

18) Page 11: Is the intent of the Media Usage History Information data such
that it can be used for any kind of media? For example, are bytes 0-3
(Current Number of Clusters Written) intended to be used for whatever the
device's "blocked or grouped" data is?

--> That's the intention. From Paul's comments below, maybe we need bytes or
MBytes rather than blocks to keep it more independent.

19) If a device supports the READ ATTRIBUTE and WRITE ATTRIBUTE commands, is
the support of all of the defined attribute ID's mandatory?

--> No. The Discovery mechanism allows for Discovery of which attributes are
supported. For instance, a cleaning cartridge may not support many
parameters.

[Dana Lane - Compaq]

Page 1:
DAL - I think we should stick with JUST the 16 byte commands. Its confusing
to have 12 byte commands and 16 byte commands. Seeing as this will only be
implemented on devices going forward, we shouldn't have much of an issue
sticking with 16. (Either way, 1 set of commands is better than 2.)

--> Need further investigaion. Still unsure whether some specific devices
have problems supporting 16 Bytes.

Page 2:
DAL - ELEMENT TYPE CODES do not apply to media. We have Storage Elements
(places that CAN store media not the media itself, Data Transfer elements,
etc... Are you implying that you want the element type code that contains
the media that contains the MAM? This is confusing. Same applies to ELEMENT
ADDRESS below. What I think you mean, is the location of the media
containing the MAM, right? We should write that up as such.

--> You are right, I will clarify.

Page 5:
ED note: Move Discovery Key to head of list. ANSI always lists fields in the
order they appear on the page. Just a nit pick.

--> Yup

Page 6:
DAL - By 'X', do we mean don't care or do we want that to be set to 0?
Should Discovery Key 1 with a valid element address, element type code, and
or volume number be an ILLEGAL REQUEST or do we want to just ignore the
other fields? Just curious.

--> I will clarify.

Page 6:
DAL - We currently ship automation devices that do not have sequential
elements. (DLT libraries are a good example). This method does not support
those configurations. Is this intended or accidental?

--> Accidential, I think I need to review the Discovery reports. See Paul's
comments.

Page 8 (example at bottom):
DAL - ED note: This field should be 'left justified'. IE, field MUST start
at byte 5 and then pad the trailing end with spaces (or 0s if binary). We
should be a little clearer here just in case.

--> I hate this example!!!!!! I will try to make it clearer and error free.

Page 9:
DAL - For Ids 0 and 1, I think we really want ACTIVE partition data and not
MAIN partition data. If the media is set up for 3 partitions, which
partition is MAIN? Also, if we're only writing to a single partition on a
multi-partitioned tape, we want to track the partition we're writing in,
don't we?

--> I'll check on this.

Page 14:
DAL - Is the intention here that the host will write this data for its own
use? Just curious.
--> Thats the intention.

[Paul Entzel - Quantum]
*	I don't see the point of both 12 byte and a 16 byte commands.  If
the single byte fields in the 12 byte CDB are sufficient for the foreseeable
future, let's live with them.  If they are not, let's go to 16 now and be
done with it.

--> See comment above.

*	On page 8, the example references an Attribute ID of 1403h, yet byte
1 is shown as a 01h.

--> See above. 

*	You may want to include a couple of more Sense Key/ASC/ASCQ
combinations for other failure conditions.  I can think of a couple right
now, such as checksum or EDC failure, or device write failure.

-> see above. 

*	I recommend that data returned with a Discover Key other than zero
be prefixed with a header.  The header should include at least the Discover
Key and the additional data length. 

--> see above. I think you're right. The same approach can cover non
contiguous element numbers.

*	The Media Usage History Information and the Partition Usage History
sections use terms not defined in this context.  Specifically, the terms
"cluster", "current", and "previous".  "Current" and "previous" are
understandable, but have no reference.  "Cluster" I suspect is format
specific to some standard outside the realm of X3.  More definition or
generalization is required here.

--> I've been wrestling with this for a while. I will do some more ...

*	The Medium Length is reported, but not its width.  Are we all
satisfied with the current tape widths?

--> Good point. On most tape drives, length is a variable, width isn't but
you never know.

*	The terms "Medium Type"  and "Density Code" are used somewhat
differently than other X3 standards.  SSC actually reports a Medium Type in
the MODE SENSE headers and a Density Code in the Block Descriptor.  The
Medium Type field is defined as Vendor Specific.  The Density Code field
refers to the REPORT DENSITY SUPPORT data, as does this document for the
Medium Type field.  Some devices can actually record more than one density
on a single medium type.  I find this whole thing confusing, especially when
you consider that this document claims a value of zero indicates cleaning
medium and SSC says it means default density.

--> I'll relook at this
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org






More information about the T10 mailing list