Question on unmapping rules

John Geldman (jgeldman) jgeldman at lexar.com
Wed Oct 20 17:19:25 PDT 2010


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

Jim,
>From my analysis, devices can implement SATA user data behavior, but the
T10 side will have to deal with unit attention.
As usual, I am ready for edification.
John
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of John
Geldman (jgeldman)
Sent: Thursday, October 21, 2010 8:46 AM
To: david.black at emc.com; 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