UNMAP clarification request

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


* From the T10 Reflector (t10 at t10.org), posted by:
* "Ballard, Curtis C (HP Storage)" <curtis.ballard at hp.com>
*
Not really, the CAP meeting minutes available under the 'Minutes' item in the
top menu is the probably the best but there are no push notifications on
minutes.  Proposal posting is sometimes announced on the reflector to raise
awareness of opportunity for comment but after that usually only tracked in
the meeting minutes.
Proposal 13-054r3, Add FORCE bit to UNMAP command, was created because some
software has implemented using UNMAP as if it were expected to always unmap
all requested LBAs and while that is usually true if the alignment and
granularity requirements are met, it isn't required to be true, so those
applications may fail in unexpected ways when a device server isn't able to
unmap all requested blocks.
That proposal has met with a lot of resistance because while some
applications may have not understood the behavior there are also a number of
applications that are using UNMAP correctly and there is already a method for
forcing all blocks to be either unmapped or zeroed in the WRITE SAME command.
 Forcing the unmap also breaks the model of UNMAP being fast and always
returning good status and is difficult to implement in some devices.  In most
cases it looks like it is better to zero blocks that can't be unmapped than
to return an error and require special error handling since most use cases
that have been described require that future reads return zero but don't
require that the LBAs actually be unmapped and that matches the WRITE SAME
functionality.
Because of the resistance it received proposal 13-054 has been removed from
the working items agenda and may not make further progress.
An alternative has been suggested but not yet written up as a formal proposal
for providing a method where a device server can report in a VPD page whether
an UNMAP command with correct granularity and alignment will result in all
LBAs being unmapped.
Another suggestion was made that we could define an option in WRITE SAME that
is something like 'prefer unmap' which would instruct the device server to
try hard to unmap blocks before deciding to write zeros.  That would be very
close to the same functionality as proposed in 13-054 but in the WRITE SAME
command which is expected to take some time instead of the UNMAP command
which is expected to be fast.
Curtis Ballard
Hewlett-Packard Company
+1 970 898 3013 / Tel 
Curtis.Ballard at hp.com / Email 
Fort Collins, CO
-----Original Message-----
From: ronnie sahlberg [mailto:ronniesahlberg at gmail.com] 
Sent: Wednesday, July 23, 2014 4:00 PM
To: Ballard, Curtis C (HP Storage)
Cc: t10 at t10.org
Subject: Re: UNMAP clarification request
Thanks,
The links were very helpful.
Would just being subscribed to this mailinglist be the proper way of
monitoring the progress/changes of 13-054r3 ?
regards
ronnie sahlberg
On Wed, Jul 23, 2014 at 2:00 PM, Ballard, Curtis C (HP Storage)
<curtis.ballard at hp.com> wrote:
> 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