Mike Christie wrote:
James Smart wrote:
This patch, discussed in the initial thread on target can_queue limits
(see http://marc.info/?l=linux-scsi&m=120944296225094&w=2 )
allows the target can_queue limit to be obtained from the device list
based on
Inquiry data obtained during scan.
I have pinged several of the array vendors to supply target-port level
values
for their arrays. Hopefully, we will see them populate the device list
with some
real values shortly.
This patch was cut against scsi-misc-2.6, and depends on Mike
Christies patches
contained in the original thread.
-- james s
PS: This sure desires the promoting of the starget in sysfs, with an
attribute
for the can_queue value.
I was thinking that for the QUEUE_FULL ramp back up problem, I would do
a userspace daemon that after some algorithm decided when it was time,
we could start increasing the queue depth.
And then I was thinking that because it needed to know when devices were
getting QUEUE_FULLs so it could figure out when to ramp back up, it
could be based off of a userspace daemon Hannes was talking about that
would pass scsi info/errors to userspace so it could be handled there
(this was originally to handle the sense data that indicated that the
lun data changed and so we were going to kick off a scan and delete old
deices from userspace).
Then I was thinking that I could extend the daemon to handle the problem
that this patch was handling too. The daemon would listen for starget or
port kobject addition events. Then it would do a inquiry to get the
target info and match it with some table, then it could write to a
straget->can_queue sysfs file to set the can_queue value.
Oh yeah, I guess it would not need to be in the error handler userspace
daemon and we could just do a udev callout for it.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
