Discussion of 14-275r7

Black, David david.black at emc.com
Tue Mar 31 17:47:51 PDT 2015


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

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.
(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.
(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?
(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.
(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.
(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?
      - 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.
(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.
(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.
(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.
Thanks,
--David
From: 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