UNMAP clarification request

Ballard, Curtis C (HP Storage) curtis.ballard at hp.com
Wed Jul 23 14:00:23 PDT 2014


* From the T10 Reflector (t10 at t10.org), posted by:
* "Ballard, Curtis C (HP Storage)" <curtis.ballard at hp.com>
*
We're still working on making this behavior abundantly clear.  I'm working on
some refinements to that text right now in
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-128r1.pdf
There is also some new text proposed in:
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-163r1.pdf
I think the key thing to catch about the UNMAP command is that the command is
supposed to be a fast command giving the device server permission to unmap
LBAs, not requiring that the LBAs be unmapped.	The device server is required
to do exactly what you see in the a/b/c list you copy below from SBC-4
sub-clause 5.25.8.  The LBAs should be unmapped but may become anchored or
may be unchanged.  Unchanged is not an error and applications should expect
that sometimes LBAs will remain unchanged, especially if alignment
requirements aren't met.  Document 14-163r1 includes text intended to make it
clear that applications can't expect deterministic behavior from UNMAP.  Use
WRITE SAME if the LBAs need to return all zeros after the command completes. 
WRITE SAME will probably be slower than UNMAP but will return deterministic
results.
I'll mix some responses below marked with [HP-CCB].
Curtis Ballard
Hewlett-Packard Company
+1 970 898 3013 / Tel 
Curtis.Ballard at hp.com / Email 
Fort Collins, CO
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of ronnie
sahlberg
Sent: Wednesday, July 23, 2014 1:34 PM
To: t10 at t10.org
Subject: UNMAP clarification request
* From the T10 Reflector (t10 at t10.org), posted by:
* ronnie sahlberg <ronniesahlberg at gmail.com>
*
List, T10 folks,
While developing tests for the UNMAP and GET_LBA_STATUS commands I have hit a
few areas where the behaviour of UNMAP is unclear, so I would like to check
thinking here and perhaps get some clarifications in the document.
I am mainly interested in unmapping of thinly provisioned devices, so assume
ANCHOR == 0 for all these cases.
Also assume that LBPPBE is 3 for all these examples so that we have 8 logical
blocks per physical block and assume that UNMAP GRANULARY ALIGNMENT is 0.
sbc-4 5.25.8 contains this wording:
If the ANCHOR bit in the CDB is set to zero and the logical unit is thin
provisioned (see 4.7.3.3), then the logical block provisioning state for each
specified LBA:
a) should become deallocated;
b) may become anchored; or
c) may remain unchanged.
but it does not explain clearly enough under which circumstances this can
happen or when check conditions will happen.
Unmap requests for ranges that are not aligned to physical block boundaries.
========================================================
A single unmap block descriptor which is not aligned to physical block
boundaries.
Assume I send an UNMAP with a descriptor containing UNMAP LOGICAL BLOCK
ADDRESS == 0 and NUMBER OF LOGICAL BLOCKS ==1 For this case I assume that the
unmap will fail and that "c) may remain unchanged" will happen if the device
can not unmap a fractional physical block.
Question 1:
In this situation, I assume that the device must return CHECK CONDITION ?
Or is the device allowed to silently not unmap the specified range and still
return SUCCESS back to the initiator?
[HP-CCB] No the device should not return CHECK CONDITION - there is no error
condition defined or expected for this case - the LBA will probably remain
mapped but the device server could unmap it even though the requirements
weren't met.
If it returns CHECK CONDITION, is it reasonable to assume that this case
should be ILLEGAL REQUEST/INVALID FIELD IN PARAMETER DATA or similar ?
Unmap requests for ranges that partially cover physical blocks.
==============================================
A single unmap block descriptor which cover one of more physical blocks but
is not properly aligned
Assume I send an UNMAP with a descriptor containing UNMAP LOGICAL BLOCK
ADDRESS == 0 and NUMBER OF LOGICAL BLOCKS == 9 For this case I assume that
the unmap will fail and that "c) may remain unchanged" will happen if the
device can not unmap a fractional physical block.
Question 2:
In this situation, I assume that the device must return CHECK CONDITION ?
Or is the device allowed to silently not unmap the specified range and still
return SUCCESS back to the initiator?
[HP-CCB] No the device should not return CHECK CONDITION - the device should
unmap every LBA it can and skip LBAs it can't unmap
If it returns CHECK CONDITION, is it reasonable to assume that this case
should be ILLEGAL REQUEST/INVALID FIELD IN PARAMETER DATA or similar ?
Question 3:
Is unmapping of a single descriptor atomic?
I.e. would the device be allowed to unmap the physical spanning LBA
0-7 and still return CHECK CONDITION because it could not unmap LBA 8 ?
I assume UNMAP can not unmap only a portion of the descriptor.	Is that
correct?
[HP-CCB] The UNMAP command "requests" unmap operations on each LBA and the
device server determines whether it can perform those operations.  The device
server either performs an operation which causes the LBA state to transition
(in your example to unmapped since anchor isn't supported) or the device
server does nothing.  All of the operations are logically performed at an LBA
level.	Devices may have a larger granularity and release blocks of LBAs
together but that doesn't have to match the set of LBAs described by a
descriptor.
Unmap requests with multiple descriptors.
===============================
Assume I send one UNMAP with two descriptors :
First descriptor is for LBA 0 and length 8 Second descriptor is for LBA 16
and length 1
Question 4:
In this situation, again, I assume that the command must return CHECK
CONDITION since one or more descriptor failed to UNMAP. Is that correct?
[HP-CCB] No - inability to unmap is not an error and won't return CC
Question 5:
Is an UNMAP operation atomic for the whole operation or only per individual
descriptor?
I.e. is the device allowed to unmap the properly aligned first descriptor and
still return CHECK CONDITION since the second descriptor failed?
[HP-CCB] Logically atomic only per-LBA, unmap what it can and skip the reset
And here comes the most important question :
Unmapping of properly aligned descriptors ===============================
Assume I send an UNMAP command to a device and the descriptors are all well
formed and perfectly aligned to physical block boundaries.
Assume I send a descriptor with LBA == 0 and NUMBER OF BLOCKS == 8 and that
it is possible for the device to unmap this physical block.
Question 6:
Is the device allowed to not perform the unmap, leaving the blocks mapped,
but still return SUCCESS ?
[HP-CCB] Yes - it is unlikely that it will but it can, use the GET LBA STATUS
if you want to check the results and use WRITE SAME if you want deterministic
results.
I think that should not be allowed. If there are blocks specified that were
not unmapped and that remains mapped after the UNMAP command completes then
the device MUST return a check condition. Is that a valid assumption?
regards
ronnie sahlberg
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org



More information about the T10 mailing list