Obsoleting 7-byte parameters in the Non-volatile Cache log page

Elliott, Robert (Server Storage) Elliott at hp.com
Thu Jun 3 17:06:29 PDT 2010


Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1006031_f.htm">HTML-formatted message</a>

Although I agree the current definitions are unclear and new parameter codes
are the best way to fix the problem, I'd like to describe how it got
confused.
The PARAMETER LENGTH field shown in SBC-2 for each of these parameter codes
was not intended to represent the PARAMETER LENGTH field in the 4-byte
parameter header. It is an (unnecessary) extra length field inside the
PARAMETER DATA field itself. So, implementations should have been:
		Byte(s) Field
Header 0:1	    PARAMETER CODE (0000h or 0001h)
Header 2	      Parameter control byte
Header 3	      PARAMETER LENGTH (04h)
Value	 4		PARAMETER LENGTH (03h)
Value	 5:7	      REMAINING NON-VOLATILE TIME   or MAXIMUM NON-VOLATILE
TIME
That would have allowed the value region for one parameter code to be
expanded to carry multiple subfields if needed.
Another plausible resolution would be to make the extra length field
Obsolete. If we are worried that some implementation might have interpreted
that extra length field as the real length field, then obsoleting these
parameter codes and assigning new ones seems best.
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Mark Evans
Sent: Thursday, 03 June, 2010 4:28 PM
To: t10 at t10.org
Subject: Obsoleting 7-byte parameters in the Non-volatile Cache log page
Hello all,
While discussing proposal 09-293, SBC-3: Log page clean-up, at the CAP
meeting in May, it was noted that the Remaining Non-volatile Time parameter
and the Maximum Non-volatile Time parameter in the Non-volatile Cache log
page are each seven bytes in length.  However, we have been trying to insure
that all SCSI parameters are four-byte aligned.
It was suggested that these two parameters be made obsolete and be replaced
with two new parameters that report the same information but are eight bytes
in length.  If there are no objections, I will do so by increasing the TIME
field to four bytes for the new parameters in the next revision of my
proposal, and I will give the parameters slightly different names.  I will
also add a note as to why this action was taken.
Please feel free to call or send an email to me with any comments or
questions that you have about this stuff.
Regards,
Mark Evans
Western Digital Corporation
5863 Rue Ferrari
San Jose, CA 95138
Email: mark.evans at wdc.com



More information about the T10 mailing list