Hi, Mike, and thank you for your reply. On Tue, Jun 8, 2010 at 10:00 PM, Mike Christie <[email protected]> wrote: > > # To control how many commands the session will queue set > # node.session.cmds_max to an integer between 2 and 2048 that is also > # a power of 2. The default is 128. > node.session.cmds_max = 128 > > # To control the device's queue depth set node.session.queue_depth > # to a value between 1 and 1024. The default is 32. > node.session.queue_depth = 32
Let me see if I understand... In this context, "device" means "Linux block device". The kernel's filesystem layer sends SCSI commands to the block device, and "queue_depth" is the maximum number of outstanding (i.e. not-yet-completed) commands the kernel will allow. In this case, the block device is implemented by the iSCSI driver, which forwards the SCSI commands over the session, which is basically the client-to-server iSCSI socket. "cmds_max" is the maximum number of outstanding (i.e., not-yet-completed) commands that the iSCSI driver will permit for the session. Is this correct so far? If so, I have a couple more questions. First, why would I want cmds_max larger than queue_depth? Is it something to do with the protocol (e.g., a single command to the device can become multiple commands in the session)? Or is it just because one session can have multiple targets, which means multiple block devices? Second, how does the number of commands relate to the amount of data being transferred? Put another way, how much data can a single command request from the disk? I realize these are very basic questions, and I appreciate your patience. - Pat -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
