Query regarding response of UNMAP command

Paul Hughes phughes at solidfire.com
Thu Feb 19 09:46:58 PST 2015


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

I agree, but SBC allows initiators to send commands that don't make much
sense (e.g. READ or WRITE with Transfer Length of zero blocks) which makes
you wonder whether the initiator is confused. On the other hand SPC has
examples of commands that require parameter data to match a certain size
(e.g. MODE SELECT, PERSISTENT RESERVE OUT).
On Thu, Feb 19, 2015 at 9:08 AM, Gerry Houlder <gerry.houlder at seagate.com>
wrote:
> I am disappointed that the SBC-4 standards doesn't require the UNMAP DATA
> LENGTH to be equal to the PARAMETER LIST LENGTH minus two. Similar
> instances in other commands call out the CHECK CONDITION response described
> by David Black in his earlier email.
>
> I am also disappointed that the standard only says "should" on the UNMAP
> DESCRIPTOR LENGTH have to be an exact multiple of the number of unmap block
> descriptors. If I were implementing the UNMAP command in a storage device I
> would reject any command that doesn't have an exact multiple with ILLEGAL
> REQUEST. i think the idea of letting the target device ignore an incomplete
> block descriptor has high risk of doing the wrong thing. For instance, the
> "shortened bytes" might be the first bytes of the first descriptor instead
> of the last bytes of the last descriptor. If this were the case then all of
> the descriptors would be incorrectly framed, the target would unmap the
> wrong LBAs (possible loss of customer data), and the command would end with
> GOOD status (the host would never know that he screwed up). A safer way to
> handle this is to ignore all of the unmap block descriptors if the list
> length isn't an exact match for an appropriate list.
>
> If all of the lengths do match but the number of data bytes transferred is
> not an exact match for the PARAMETER LIST LENGTH, the the underlying
> protocol (e.g., SAS protocol layer) would detect a data underrun or data
> overrun. This would result in a response packet (for SAS) that indicates
> the error. This procedure will vary depending on how your particular
> protocol layer handles data underrun and overrun situations.
>
> On Thu, Feb 19, 2015 at 8:55 AM, Black, David <david.black at emc.com> wrote:
>
>> * From the T10 Reflector (t10 at t10.org), posted by:
>> * "Black, David" <david.black at emc.com>
>> *
>> In general, truncated UNMAP block descriptors are ignored.
>>
>> > For example, host wants to transfer single block descriptor with UNMAP
>> > command. In this cases following values shall be driven:
>> > PARAMETER LIST LENGTH= 'h18 (24),
>> > UNMAP DATA LENGTH= 'h16 (22),
>> > UNMAP BLOCK DESCRIPTOR DATA LENGTH= 'h10 (16).
>> >
>> > Here, if host transmits other than 'h16 value for UNMAP DATA LENGTH
>> > field or other than 'h10 for UNMAP BLOCK DESCRIPTOR DATA LENGTH field,
>> > then which of the following behavior of device is correct:
>>
>> There's no single answer.
>>
>> If those values are smaller than stated above, and are consistent,
>> the UNMAP block descriptor is incomplete and is ignored; nothing happens
>> and GOOD status is returned.
>>
>> If those values are larger than stated above, and are consistent, then the
>> PARAMETER LIST LENGTH in the CDB truncated the parameter data; the one
>> complete UNMAP block descriptor that was received is processed and the
>> truncation is not an error.
>>
>> If those two values are inconsistent, the shortest one governs whether
>> a complete UNMAP block descriptor was received, and it's ok to proceed
>> as above.  It's probably a better idea to note the inconsistency
>> (especially
>> if UNMAP DATA LENGTH is too small by comparison to UNMAP BLOCK DESCRIPTOR
>> LENGTH) and treat that as an error -
>> CHECK CONDITION, ILLEGAL REQUEST, INVALID VALUE IN PARAMETER LIST.
>>
>> Thanks,
>> --David
>>
>> > -----Original Message-----
>> > From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Munjal
>> Mistry
>> > Sent: Thursday, February 19, 2015 6:18 AM
>> > To: T10 Reflector
>> > Subject: Query regarding response of UNMAP command
>> >
>> > * From the T10 Reflector (t10 at t10.org), posted by:
>> > * Munjal Mistry <munjal_mistry at mentor.com>
>> > *
>> > Hi,
>> >
>> > I have a query regarding the response for UNMAP command when there is
>> > mismatch of "PARAMETER LIST LENGTH" (field of UNMAP command) with "UNMAP
>> > DATA LENGTH" or "UNMAP BLOCK DESCRIPTOR DATA LENGTH" (fields of unmap
>> > parameter list).  Here, Storage device is thin provisioning.
>> >
>> > For example, host wants to transfer single block descriptor with UNMAP
>> > command. In this cases following values shall be driven:
>> > PARAMETER LIST LENGTH= 'h18 (24),
>> > UNMAP DATA LENGTH= 'h16 (22),
>> > UNMAP BLOCK DESCRIPTOR DATA LENGTH= 'h10 (16).
>> >
>> > Here, if host transmits other than 'h16 value for UNMAP DATA LENGTH
>> > field or other than 'h10 for UNMAP BLOCK DESCRIPTOR DATA LENGTH field,
>> > then which of the following behavior of device is correct:
>> >
>> > (1) Device ignores it's value and unmap the logical blocks described
>> > with UNMAP block descriptor and sends GOOD response.
>> > (2) Device ignores it's value and unmap the logical blocks described
>> > with UNMAP block descriptor and sends failure response.
>> > (3) Device terminates the command and sends failure response.
>> >
>> > If device sends the failure response, as per the 2nd and 3rd behavior
>> > then what would be the possible status, ASC and ASCQ for failure?
>> >
>> >
>> > --
>> > Warm Regards,
>> > Munjal Mistry
>> >
>> > *
>> > * For T10 Reflector information, send a message with
>> > * 'info t10' (no quotes) in the message body to majordomo at t10.org
>>
>> *
>> * For T10 Reflector information, send a message with
>> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>>
>
>
-- 
*Paul HughesSenior Software Engineer, SolidFire, Inc.*
e: phughes at solidfire.com
*Advancing the way the world uses the cloud
<http://solidfire.com/solution/overview/?video=play&gt;**â„¢*



More information about the T10 mailing list