On 01/05/2011 10:14 PM, Mike Christie wrote:
On 01/05/2011 03:05 PM, Mike Christie wrote:
does not care about it and I still have about 200 inflight commands at
any time.

Isn't the queue_depth the max number of inflight commands?

Not exactly. A problem is that queue_depth is a scsi layer limit and is
tracked in that scsi layer. But, inflight is a gendisk/block stat and is
tracked there, so they mean slightly different things.

queue_depth - limit of how many commands that can be sent to the scsi
device at any time.

block/gendisk inflight - how many requests are queued on the request_queue.

inflight can be higher because you can have lots of requests in the
queue, but the scsi layer would only take queue_depth worth of them at
any time to send to the device.

Oh yeah, there is not something that exactly shows the number of commands sent to a device. If you are using 1 device on a host you can cat /sys/class/scsi_host/hostX/host_busy (this tells you how many commands are running on the host at any time).

Wonderful! It works then!

And there is a blktrace value that tells you how many requests have been dequeued but not have been completed (I am not sure what that is off the top of my head and you would have to search google for it), but that might be slightly off since that is block layer accounting and the queue_depth is in the scsi layer.

Right! It seems to be the number in square brackets, especially in an "unplug" line (like man blkparse says in some man versions).

May I also ask what is the /dev/block/device/queue/nr_requests ?
I thought it was the max length of the request queue, but... if I set a low number like 32 I often see higher values with iostat -x 1 in avgqu-sz. E.g. now it's at 32 and I saw a 58. Is it maybe because it can reach 2*nr_requests, that is, nr_requests for writes and again nr_requests for reads?

Thank you

You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-is...@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to