Mike Christie wrote:
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.
So what I am asking is we can do the setting of starget->can_queue from:
1. kernel devinfo table like in this patch.
2. udev rule.
3. userspace scsi daemon that handles lots of junk scsi-ml in the kernel
does not want to handle.
--
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
