Discussion of 14-275r7
John Geldman (jgeldman)
jgeldman at micron.com
Tue Mar 31 19:26:27 PDT 2015
Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1503311_f.htm">HTML-formatted message</a>
I will add a completely unrelated comment on this thread. Just above 5.97 on
pdf page 27 is the paragraph:
Physical blocks that are part of the stream granularity size block that do
not contain data when a stream is closed should not be allocated to other
logical block data until the entire block is unmapped.
There are several issues packed into this short paragraph to:
(1) LBA's that may have been allocated to a physical block are unmapped not
(2) I am confused by the unmap language in this paragraph. We have an
unmapped state for each LBA that may occur after the host tells the device
that the data in specified LBA's has been released by the host. I think a
more general usage was intended.
(3) It is out-of-scope to completely prohibit new allocations to the physical
block. Consider the case where four physical resources are allocated to a
stream, but there is only scare valid data remaining when the stream is
closed. The device should not be prohibited from garbage collecting (merging)
the sparse contents of the four allocated physical resources reserved for
that stream into possibly one packed physical resource that is still reserved
for that stream.
Director, Industry Standards
540 Alder Drive
Milpitas, CA 95035
email:jgeldman at micron.com
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Black, David
Sent: Tuesday, March 31, 2015 5:48 PM
To: Bill Martin-SSI; T10 Reflector
Subject: RE: Discussion of 14-275r7
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
(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
(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 184.108.40.206.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 220.127.116.11 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.
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.
SSD I/O Standards
Samsung Semiconductor, Inc.
Cell (408) 499-1839
More information about the T10