Discussion of 14-275r7

Bill Martin-SSI bill.martin at ssi.samsung.com
Wed Apr 1 08:04:32 PDT 2015


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

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> [mailto: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