Issues with 14-128r2: unmap clarifications

Ballard, Curtis C (HP Storage) curtis.ballard at hp.com
Tue Sep 9 06:18:21 PDT 2014


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

Thanks for the comments Naren,
Fred did a good job responding to most of the comments.  I have fixed the
list numbering for the next revision.
I'll fill in some further explanation.
1)	Sanitize results: The requirement is there today that following a
sanitize every LBA "should" be anchored (resource provisioned devices) or
deallocated (thin provisioned devices).  I don't want to make any changes to
the existing requirement, just help explain/justify the existing requirement.
 How the LBA's end up unmapped (deallocated/anchored) is kind of left to the
imagination given the model that exists today.	The model doesn't have any
text for a sanitized device with LBAs that can be some random value suddenly
ending up unmapped.  The (i.e.) statement is intended to help provide a link
|from the model to the result, each LBA is treated as if the logical block
data been set to zero, then an autonomous transition changed the LBA
provisioning state to deallocated or anchored.	The sanitize operation knows
that the data is no longer valid and can be treated as if it is zero.  The
logical block data for the LBA doesn't have to actually be set to zero, it is
just modeled as if it had been.  I expect an interesting discussion on this
text and the wording probably will be improved following the meeting.
2)	Commands versus operations: As Fred indicated, it is important to
separate the commands from the operations.  SBC-3 and SBC-4 distinguish
between commands that request operations and the operations that do the work.
 That is true for read/write/verify/unmap/etc - the model is common.  In this
case,  unmap commands request an unmap operation for each LBA and the device
server either performs an unmap operation on the LBA or does nothing for that
LBA.  The unmap operation doesn't have a 'failed' case, it is either
performed or not.  If the unmap operation is performed then it always results
in a transition to deallocated or anchored.  For the case below, the text is
pointing out that the anchored bit set to one requires that the transition
result in anchored.  If the LBA can't be transitioned to anchored, then the
unmap operation is not performed on that LBA.
Curtis Ballard
Hewlett-Packard
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Knight,
Frederick
Sent: Monday, September 8, 2014 3:10 PM
To: Nadesan Narenthiran; T10 Reflector
Subject: RE: Issues with 14-128r2: unmap clarifications
FK>>Inline
From: owner-t10 at t10.org<mailto:owner-t10 at t10.org> [mailto:owner-t10 at t10.org]
On Behalf Of Nadesan Narenthiran
Sent: Monday, September 08, 2014 2:09 PM
To: T10 Reflector
Subject: Issues with 14-128r2: unmap clarifications
Hi,
The change at the top of page 3 for section 4.11.3 (completing a sanitize
operation) is a new requirement on drives.  The proposed text says,
the initial condition for every LBA should be anchored (see 4.7.3.2) or
deallocated (see 4.7.3.3) (i.e.,
LBAs that have been sanitized should be set to zero and autonomous LBA
transitions (see 4.7.3.5)
result in the LBAs becoming anchored or deallocated); and
Currently a Cryptographic Sanitize operation is not required to set any
particular value for the user data.  The host is only guaranteed consistent
garbage data afterwards.  However this new text requires all zero data to be
returned for the read command.	I think this part of the change should be
clarified or struck.
This is not a requirement, it is inside an i.e. - that means it is further
clarifying the previous statements - that being what it means to be anchored
or deallocated.  Go look at the consequences of the anchored state (4.7.3.2)
and the deallocated state (4.7.3.3), and you'll see that this "i.e." text is
really just explaining the consequences of being in those states.  It is just
a restatement of what is ready there, not a new requirement.
Someone with a better understanding on thin provisioned logical units should
look at the middle of page 4 at the text
For a thin provisioned logical unit (see 4.7.3.3) with the ANC_SUP bit set to
zero in the Logical Block Provisioning
VPD page (see 6.6.4):
b) an ANCHOR bit set to one specifies that the device server shall terminate
the command with CHECK
CONDITION status with the sense key set to ILLEGAL REQUEST and the additional
sense code set
to INVALID FIELD IN CDB; and
a) an ANCHOR bit set to zero specifies that any LBA on which an unmap
operation is performed shall
become deallocated.
I am guessing that the wording on item a (second item on this list) should be
a "should" and not a "shall"; Or that the wording should be a copy of item a
|from the previous list.
The a) text is correct.  If ANC_SUP is set to zero, then the anchor state is
not supported; only the mapped and deallocated states are supported (see:
4.7.4.3 LBP state machine for thin provisioned logical units not supporting
anchored LBAs).  Therefore, when an unmap operation IS performed (remember,
unmap operations occur on per a LBA basis); that LBA has only one choice for
a state - it can only be deallocated.  It is not a SHOULD, it is a SHALL. 
Remember, we are not talking about an unmap command that may or may not
result in unmap operations, we are talking about what happens WHEN the actual
unmap operation occurs.
If the LBA did not transition to the deallocated state and the LBA is still
in the mapped state, then the unmap operation was NOT performed.
BTW, noting that item numbering needs to be corrected in a number of lists
(example at above location).
Have a nice day.
Naren.



More information about the T10 mailing list