Issues with 14-128r2: unmap clarifications

Nadesan Narenthiran Nadesan.Narenthiran at hgst.com
Tue Sep 9 13:39:23 PDT 2014


Attachment #1: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1409093_nameless-3200-2-1.html">nameless-3200-2-1.html</a>

Thanks for the responses Curtis and Fred.  I understand the explanations on
the thin provisioning case.  But I still do not understand the explanation,
did not explain the issue properly, or do not agree on the first issue.
4.11.3 is about the sanitize operation, not the unmap operation.  Previously
a sanitize operation required the LBA to be anchored or deallocated. 
Anchored does not have any requirement on the data other than to be
consistent (the data need not be set to zero).	For the sanitize operation,
this is because of the crypto sanitize case (what I pointed out) and the
overwrite case (what Jerry pointed out).  In both cases the end result of the
sanitize operation will be non-zero data on the sanitized logical blocks; And
in both cases this is not just the physical data in the medium but the data
that is expected to be returned to the host (depending on WABREQ, WACEREQ,
etc).
I looked at 4.7.3.2 and 4.7.3.3 and did not see any requirement on setting
the data to zero.  Unless I missed it, this is still a new requirement and
not clarifying what existed before.
If the sanitize operation has been modelled as making all logical block data
to be zero regardless of the sanitization type, then there are major
disconnects and I do agree there will be interesting discussions in CAP.
It would be an acceptable (though I do not like it) argument that it is only
a "should" and hence fine to be wrong for half the cases.
It may also be acceptable to clarify that the "i.e." only pertains to the
deallocate case and remove the "anchored" word from the "i.e." sentence.  I
do not think there is an existing requirement to return zero data from
deallocated blocks either.  However there definitely are practical or derived
requirements to do so.
Have a nice day.
Naren.
From: Ballard, Curtis C (HP Storage) [mailto:curtis.ballard at hp.com]
Sent: Tuesday, September 09, 2014 6:18 AM
To: Knight, Frederick; Nadesan Narenthiran; T10 Reflector
Subject: RE: Issues with 14-128r2: unmap clarifications
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> [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