UNMAP clarification request

ronnie sahlberg ronniesahlberg at gmail.com
Wed Jul 23 12:34:08 PDT 2014


* 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?
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?
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?
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?
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?
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 ?
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



More information about the T10 mailing list