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
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
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?
You received this message because you are subscribed to the Google Groups
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