Latest Media Auxilary Memory Access Specification
wolfe at intellistor.com
Wed Oct 27 15:24:10 PDT 1999
* From the T10 Reflector (t10 at t10.org), posted by:
* Keith Wolfe <wolfe at intellistor.com>
JERMAN,STEVE (HP-Boise,ex1) wrote:
> The latest MAM Access proposal is now on the T10 web site ready for
> discussion at the next SCSI Working Group meeting in Monterey.
> If anyone has comments before the meeting, I will be happy to take them.
> Steve Jerman, HP
> (208) 396 5618
Thanks for the update, I reviewed the document and came up with the
following issues. I'm looking forward to hearing about the results of the
meeting in Monterey next week and to any reply you can give to the issues
The following 19 items are in response to the PROPOSED ADDITION OF READ
AND WRITE ATTRIBUTE COMMANDS TO SPC-2, by Steve Jerman, dated 10/22/99.
This document has an ANSI T10 document number of T10/99-148r3.
1) Are READ ATTRIBUTE and WRITE ATTRIBUTE optional commands?
2) What was the motivation to drop the proposal to support
MAM access via Log Sense and Log Select?
3) What is the state of the Inquiry Auxiliary Memory page 84h?
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
tape drive, but auxiliary memory read/write accesses have failed).
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'
6) Page 3, paragraph 1 and page 5, paragraph 1: Since the WRITE ATTRIBUTE
READ ATTRIBUTE commands use "elements", it would be helpful to
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
referring to a device-specific command set (e.g. SMC).
7) Page 4, paragraph 3: Is the 'ATTRIBUTE LIST LENGTH ERROR'
ASC/ASCQ new? Why not use 'PARAMETER LIST LENGTH ERROR'?
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
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
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
11) Page 7, last paragraph: shouldn't 'WRITE ATTRIBUTE' be 'READ
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?
13) Page 8, paragraph 7: The description of clearing attributes is a little
confusing. I have a couple of questions with regard to clearing
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?
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)?
c) Could a mechanism be implemented such that an attribute could be
cleared and still be reported in response to a subsequent READ
14) Page 8, byte 1 in example at bottom of page: Byte 1 should be 03h,
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
16) Page 9: Is the Load Count attribute (ID 0003h) the same as bytes 48-51
in the Media Usage History Information?
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?
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?
19) If a device supports the READ ATTRIBUTE and WRITE ATTRIBUTE commands,
is the support of all of the defined attribute ID's mandatory?
- END -
* 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