Question on unmapping rules

James C Hatfield james.c.hatfield at seagate.com
Wed Oct 20 16:00:02 PDT 2010


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

Thinking of the SAT consequences..... (mapping MODE SELECT)...
In ATA:
- if you hide LBAs using SET MAX ADDRESS, the hidden data does not change.
When you later unhide it with SET MAX ADDRESS, the hidden data shall be
retained. That's the whole purpose behind the feature.
- if you hide LBAs using DCO SET, the standard is silent on whether or not
the hidden data is retained.
Thank You !!!
-----------------------------------------------------------------
Jim Hatfield
Seagate Technology LLC
   e-mail:  James.C.Hatfield at seagate.com
   s-mail:  389 Disc Drive;  Longmont, CO 80503 USA
   voice:  720-684-2120
   fax....: 720-684-2711
   cell...: 720-771-8914
On Wed, Oct 20, 2010 at 4:07 PM, <david.black at emc.com> wrote:
>  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