[T10] Rumination on some WRITE SCATTERED command considerations

Knight, Frederick Frederick.Knight at netapp.com
Sun Jan 10 07:11:01 PST 2016


You said – ‘host being surprised by a "sudden reduction" in the target's queue slots’

And how would a host be “surprised”? There is no way for a host to know how many queue slots there are, nor is there any way for a host to know what other initiators are doing to impact the queue slots.  Host must be prepared to handle QUEUE FULL at any for any reason a device chooses to return it.  But, it’s not just queue slots that are at issue.

Consider the EXTENDED COPY command – while single spindle disks may not have thought about it much, this command has a HUGE impact on the resources available with a device (including queue slots).  One single command requesting both reads and writes that cover many disparate LBA ranges of many different lengths, and possibly, across may different LUNs.

Any such warning is not WRITE SCATTERED specific.

I will add, that experiences with EXTENDED COPY indicate that hosts DO BELIEVE that all commands are created equal (i.e., that all commands use the same amount of device resources, no matter what the OP CODE). YES, we actually have people that think that 1 READ command plus 1 WRITE command use TWICE the resources as 1 EXTENDED COPY command that performs the exact same READ and WRITE operations (they failed to grasp the concept that, internal to the device, it still impacts the same amount of data).

It might be worthwhile to add a model clause that talks about resource utilization related to complex commands (such as these).

            Fred

From: t10-bounces at t10.org [mailto:t10-bounces at t10.org] On Behalf Of Gerry Houlder
Sent: Thursday, January 07, 2016 11:38 AM
To: T10 Reflector
Subject: [T10] Rumination on some WRITE SCATTERED command considerations

Hi T10ers,

One detail that has not been aired during recent discussion on the WRITE SCATTERED command is how this command affects the available queue depth in a SCSI target. in particular there is the rule that allows the LBA range descriptors to be processed in any order.

i can see how the command can occupy only one queue slot if the LBA range descriptors are processed in the order received and doesn't allow activity for other commands to be interspersed between the LBA range descriptors. This is comparable to the way (vendor specific) skip mask write commands are handled today

I can forsee that, in order to process the LBA range descriptors in any order, a SCSI target might choose to treat each LBA range descriptor like it is a separate command (i.e., each LBA range descriptor occupies a separate queue slot in the command queue). This could result in the host being surprised by a "sudden reduction" in the target's queue slots and the rejection of other commands due to Queue Full status.

 Another side effect of this is that the command timer (normally attached to each queue slot) now has to time the processing of multiple queue slots, the processing of which might be interspersed with high priority commands that are not part of the LBA descriptor list.

Should there be some warnings added to the scattered writes model, that a single WRITE SCATTERED command may result in multiple command queue slots being occupied by that single command?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.t10.org/pipermail/t10/attachments/20160110/00313d09/attachment.html>


More information about the T10 mailing list