Comments So Far on MAM Proposal

JERMAN,STEVE (HP-Boise,ex1) steve_jerman at am.exch.hp.com
Fri Oct 29 11:47:14 PDT 1999


* From the T10 Reflector (t10 at t10.org), posted by:
* "JERMAN,STEVE (HP-Boise,ex1)" <steve_jerman at am.exch.hp.com>
*
Hi,

isn't email a wonderful invention ... thanks for your attention.

See below for my responses. 

-----Original Message-----
From: Keith Wolfe [mailto:wolfe at intellistor.com]

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

*KW>  I agree multiple definitions should be avoided.  This would require
the
element definitions to be moved from the SMC to SPC-2.  The theory behind
this
is that device-specific commands can reference definitions/commands in the
Primary Command set, however, commands in the Primary Command set should not
be
based on device-specific definitions.

SJ> I think this will need talking through at the meeting. I can see merits
in both options.

> 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.'

*KW>  This is precisely my question.  If the available space does not fall
on
the boundary of a "complete" attribute, then should only the last complete
attribute be sent (even though the available space has not been filled) or
should the next attribute also be sent and truncated so that the exact
number
of bytes of available space are filled?  In other words, the Allocation
Length
bytes or all of the available bytes of data are sent, whichever is less,
regardless of whether the last attribute is truncated.  I believe this is
the
way other commands such as Log Sense, Mode Sense, etc. work.

SJ:>My original intention was that only the last complete attribute would be
sent. We should probably be the same as other commands though .. so maybe I
need to change to your interpretation.

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

*KW> (a) above requires parameter data to be sent with zero length
attributes.
With a mechanism like an 'ADR' (Attribute Data Reset) bit in the
WRITE ATTRIBUTE command, no parameter data would be required and all host
changeable attributes could be cleared.

SJ> maybe that would be a good way to do it?

> [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.

*KW>  Even though two CDB formats for these commands might be a little
confusing, we would like to see the 12-byte format remain because not all
SCSI HIPC's (Host Interface Protocol Controller chips) support 16-byte
CDB's,
even though they support many other SCSI-3 capabilities.  Is it possible to
have just the 12-byte CDB's?

SJ:> Again this is a topic for discussion at the working group meeting. The
downside of using 12 byte CDB's is thatthey would clash with some CD/DVD
devices.
*
* 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