Question on unmapping rules

david.black at emc.com david.black at emc.com
Wed Oct 20 17:31:05 PDT 2010


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

One more case for expansion: A resource provisioned device is obligated to at
least anchor (and it may map) the LBAs for the expanded space.	IMHO, it's
reasonable to assume that a resource provisioned device has the resources to
do this (if not, it should have rejected the MODE SELECT command that did the
expansion).
Thanks,
--David
From: John Geldman (jgeldman) [mailto:jgeldman at lexar.com]
Sent: Wednesday, October 20, 2010 7:46 PM
To: Black, David; gerry.houlder at seagate.com; t10 at t10.org
Subject: RE: Question on unmapping rules
I have a slightly different perspective to directly answer Gerry's question.
I wondered what happens to user data in a block that is contracted and
re-expanded.
What I found is a requirement to report the change and a warning that data
may be corrupted.
I came up with two conclusions, (unless we add new requirements).
A contracted device with logical provisioning is not obligated, but has an
opportunity to unmap.
An expanded device with logical provisioning has unformatted data and has
options:
		fully provisioned devices would have resources, but they are
not obligated to be mapped (or formatted); and
		thin provisioned devices may or may not have sufficient
resources and aren't obligated to map (and potentially create resource
exhaustion).
>From sbc3424, 4.9, I found:
A direct-access block device may become format corrupt (e.g., a change in the
number of logical blocks
results in ranges of logical blocks with different logical block lengths or
multiple protection types) after
processing a MODE SELECT command that changes parameters related to the
medium format. During this
time, the device server may terminate medium access commands with CHECK
CONDITION status with the
sense key set to NOT READY and the appropriate additional sense code for the
condition.
Any time the parameter data to be returned by a device server in response to
a READ CAPACITY (10)
command (see 5.14) or a READ CAPACITY (16) command (see 5.15) changes (e.g.,
when a FORMAT UNIT
command or a MODE SELECT command completes changing the number of logical
blocks, logical block
length, protection information, or reference tag ownership values, or when a
vendor specific mechanism
causes a change), then the device server shall establish a unit attention
condition for the SCSI initiator port
(see SAM-4) associated with each I_T nexus, except the I_T nexus on which the
command causing the
change was received, with the additional sense code set to CAPACITY DATA HAS
CHANGED.
Bottom line, I think mapping on capacity change by MODE SELECT is vendor
specific today. While buyers may have different opinions, it is less
problematic to unmap contracted user areas and not  to map expanded user
areas. (let them be wrong until they are write).
John Geldman
Director, Industry Standards
Lexar Media Inc. (a Micron Technology Inc. subsidiary)
47300 Bayside Parkway
Fremont, CA 94538
P: 510-580-8715
C: 510-449-3597
** Lexar/Micron Confidential **
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
david.black at emc.com
Sent: Thursday, October 21, 2010 7:08 AM
To: gerry.houlder at seagate.com; t10 at t10.org
Subject: RE: Question on unmapping rules
Hi Gerry,
The no longer accessible LBAs are no longer visible through the SCSI
interface (ok, that was obvious, bear with me ...).  Because those LBAs are
not visible, their mapping (logical block provisioning) state
(mapped/anchored/deallocated, unmapped = anchored OR deallocated) is also not
visible.  For example, attempting to query the mapping state of the no longer
accessible LBAs with the GET LBA STATUS command should result in CHECK
CONDITION, ILLEGAL REQUEST, LOGICAL BLOCK ADDRESS OUT OF RANGE, which is also
the expected response to attempting I/O to those LBAs.
As SCSI is an Interface standard and the no longer accessible LBAs are not
visible through the Interface, the implementation should be free to do what
it likes with resources that were used by those no longer accessible LBAs.
Unfortunately, in looking at the GET LBA STATUS command, I see an LBA range
check on the LBA in the CDB, but no clear instructions to the device server
that LBA status is only to be returned for accessible LBAs.  That appears to
be an oversight - I think that it would be appropriate to add such
instructions if that would help to resolve this confusion.
If LBAs become inaccessible and their accessibility is subsequently restored,
I believe that the "initial condition of every LBA" requirement language
applies to the newly visible LBAs - those requirements are currently located
in 4.2.3.2 and 4.2.3.3 in 10-233r6, and I would have no problem with a
proposal to add language elsewhere to clarify the applicability of those
requirements to this situation.
Thanks,
--David
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Gerry Houlder
Sent: Wednesday, October 20, 2010 2:23 PM
To: T10 Reflector
Subject: Question on unmapping rules
Hi gang,
A question has been posed about how to handle the mapped/ unmapped state of
LBAs when the capacity of a drive is reduced (e.g., using MODE SELECT with a
block descriptor that reduces the maximum capacity). I can't find any words
in SPC-4 or SBC-3 that explicitly address this case.
If the no longer accessible LBAs (e.g., ones above the new max address but
below the old max address) were mapped, should the remain mapped or are they
permitted to be unmapped? I think the handling is obvious if those LBAs were
already unmapped (they can remain unmapped) but the previously mapped case is
not so obvious. Any opinions?
Should there be a proposal to add this handling to SBC-3?



More information about the T10 mailing list