Discussion of 14-275r7

Gerry Houlder gerry.houlder at seagate.com
Wed Apr 1 08:25:08 PDT 2015


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

i am concerned that the interaction of this command with the various PI
types is not well defined.
The WRITE STREAM command includes all of the needed fields to work with PI
type 2, but nothing is added to the Protection Information model clauses
that indicate which protection types this is allowed for. The added fields
would allow the command to be used with PI type 2 systems, but the
equivalent WRITE (32) command is defined to not be allowed for PI types 0
and 1. If you only intended this feature to work with PI type 2, then the
STREAM_ID field could just have been added to the existing WRITE (32) --
since you are creating a new command I presume you intend that it be used
with at least PI type 0 as well. If you want to include PI type 1 also,
then there should be some new rules that allow the storage device to ignore
the EXPECTED INITIAL LOGICAL BLOCK REFERENCE TAG and use the LOGICAL BLOCK
ADDRESS field (like PI type 1 does) instead for the expected initial
logical block reference tag. The new rules should be added to the Protect
Information Model clause (4.22) and probably includes some changes for all
three PI type clauses to accommodate the new command.
On Wed, Apr 1, 2015 at 10:04 AM, Bill Martin-SSI <
bill.martin at ssi.samsung.com> wrote:
>  David:
>
>
>
> Thank you for your comments. Please see inline comments. I will add your
> comments to a commented version of the document to be discussed later
today.
>
>
>
> Bill Martin
>
> SSD I/O Standards
>
> Samsung Semiconductor, Inc.
>
> Cell (408) 499-1839
>
>
>
>
>
>
>
> *From:* Black, David [mailto:david.black at emc.com]
> *Sent:* Tuesday, March 31, 2015 5:48 PM
> *To:* Bill Martin-SSI; T10 Reflector
> *Subject:* RE: Discussion of 14-275r7
>
>
>
> Bill,
>
>
>
> Here are some comments from the promised EMC review of 14-275r7:
>
>
>
> (1) Number of streams, i.e., size of STR_ID.	We’ve never seen a good
> explanation for why a large number of streams (e.g., current STR_ID is 16
> bits) are needed, and in particular we are highly skeptical of the notion
> that a stream per virtual machine is a good idea on granularity, data
> lifetime and VM lifetime grounds that I’m willing to explain further on
> tomorrow’s call.  We actually think that a much smaller number of bits
> (e.g., 3 or 4) for STR_ID will suffice for the use cases that we do
> understand for streams.
>
>
>
> <wrm> I agree that a smaller number is possible, but I have applications
> that require something greater than 32. I had originally looked at using
> the group field for yet another purpose, but this was overloading the use
> of that field as there are applications that would like to use additional
> hints on top of the stream concept.
>
>
>
> (2) WRITE STREAM.  The facts that existing SCSI write commands do not work
> with streams and hence that a brand new WRITE STEAM command with a 32-byte
> CDB is necessary have always been troubling.	If the number of streams that
> need to be supported is reduced dramatically, there may be other options to
> enable the existing SCSI write commands to work with streams.
>
>
>
> <wrm> one concern about using the existing WRITE(32) command is that this
> now REQUIRES type 2 protection information. Are you proposing that this
> might fit into a WRITE (16) command?
>
>
>
> (3) Q: Armed-increasing percentage thresholds.  The existing capacity
> thresholds are defined for both armed-increasing (trigger on increased use
> of resources) and armed-decreasing (trigger on decreased availability of
> free resources) bases.  The new percentage thresholds appear to have been
> specified as armed-decreasing only in Table 4.  What is the rationale for
> omitting armed-increasing percentage thresholds?
>
>
>
> <wrm> for our application, armed decreasing is all that is needed. At any
> point armed increasing could be added without backwards compatibility
> issues.
>
>
>
>
>
> (4) Minor: The 4.32 model clause for background operation control looks
> like a problem waiting to happen if we ever apply thresholds to anything
> other than LBA mapping resources - that text should specify that the
> thresholds involved are for LBA mapping resources now.
>
>
>
> <wrm> I am not sure where you want to add this, but am not adverse to
> adding this in the right place.
>
>
>
> (5) Minor: The mention of media read and write operations in the EXAMPLE
> in 4.32 seems incomplete, as such operations are also performed as part of
> processing an I/O command.  Inserting “(e.g., for garbage collection)”
> would be helpful.
>
>
>
> <wrm> The example is an example of what may be done by advanced background
> operations not all things that would cause the listed operations to be
> performed.
>
>
>
> (6) 4.32 seems unclear on when the device-server is allowed to initiate
> advanced background operations on its own:
>
>	- The first paragraph references threshold minimum as if there’s
> only one threshold.  What if there is more than one?
>
>
>
> <wrm> I agree. I would suggest changing “if the available provisioning
> resources fall below the threshold minimum (see 4.7.3.8.4), then” to
“if
> the available provisioning resources fall too low, then ...”
>
>
>
>	- The text on MINIMUM PERCENTAGE seems duplicative wrt the threshold
> framework.  Why was that done?
>
> Part of the problem may be that the text in the first paragraph for
> “threshold minimum” and the 4.7.3.8.4 reference are off the mark, and
that
> text should be about MINIMUM PERCENTAGE, but something is peculiar here;
> there should be exactly one threshold or minimum beyond which the device
> server does this on its own.
>
>
>
> <wrm> I agree in principal and think that the change suggested captures
> this fact and removes the linkage to a specific threshold.
>
>
>
> (7) The initial state of all logical blocks in a resource provisioned
> logical unit that supports the anchored state now may be deallocated.  This
> doesn’t seem like a problem, but it is a change that others should check.
>
>
>
> <wrm> I think that you are pointing to the wording in 4.7.4.2, and I agree
> that this may be an issue in that the intent was that this was allowed to
> be the initial state if you are resource provisioned and do not support the
> anchored state. I would suggest that the initial state be qualified with
> whether the device supports the anchored state. I will propose wording on
> the call.
>
>
>
> (8) Something’s wrong with the LBP state machines.	As resource
> provisioned logical units are now specified to always allow the deallocated
> state, I think Section 4.7.4.4 needs to be deleted.
>
>
>
> <wrm> Agreed, and accepted as a change to the next version.
>
>
>
> (9) Minor: In 4.33:
>
>
>
> Stream write operations that are aligned to the value and the length
>
> specified in the OPTIMAL STREAM WRITE SIZE field in the Block Limits
> Extension VPD page
>
> (see 6.6.9) provide optimal performance from the device.
>
>
>
> That text seems off.	Suggestion:
>
>
>
> Stream write operations whose size matches the value specified in the
> OPTIMAL STREAM WRITE SIZE field
>
> in the Block Limits Extension VPD page, and whose initial LBA is either
> zero or a multiple of that size
>
> (see 6.6.9) provide optimal performance from the device.
>
>
>
> <wrm> Agreed, and accepted as a change to the next version.
>
>
>
> Thanks,
> --David
>
>
>
> *From:* owner-t10 at t10.org [mailto:owner-t10 at t10.org <owner-t10 at t10.org>]
*On
> Behalf Of *Bill Martin-SSI
> *Sent:* Tuesday, March 17, 2015 1:51 PM
> *To:* T10 Reflector
> *Subject:* Discussion of 14-275r7
>
>
>
> Please review 14-275r7 which was the outcome of the last T10 meeting
> week. If you have any concerns, please email them to me prior to the April
> 1 meeting, so that I can implement proposed fixes prior to that meeting. As
> I attempted to move this forward at the last meeting, I would like to get
> any concerns early so that it is possible to move this forward at the next
> meeting.
>
>
>
> Thanks,
>
>
>
> Bill Martin
>
> SSD I/O Standards
>
> Samsung Semiconductor, Inc.
>
> Cell (408) 499-1839
>
>
>
>
>



More information about the T10 mailing list