On Tue, Dec 07, 1999 at 08:38:07PM -0500, Eric Youngdale wrote:
>
> Oh, duh! Now I remember why it is broken. I ran across it when I
> redid the queueing code, and it struck me that not many people could be
> using the existing code, because there was no way that it could have
> worked. I *think* I fixed the problem in the new queueing code, but we
> will find out for sure once it hits the street.
>
> The single lun code basically needs to figure out if any of the
> other luns for the physical device are active or not. It does this by
> walking the command blocks for the device and seeing whether any of them
> are active.
[ ... ]
> I don't have the code in front of me, but the "quick" fix for the
> problem is that in the single-lun case we need to add an outer loop which
> iterates over all of the devices attached to the host, and then for each
> device that has the same target ID and channel number, then search the
> command blocks for anyone that is busy.
>
> I should add, however, that in the long run this isn't the right
> fix. There is a known problem where we over-allocate the command blocks
> with the current pre-allocation scheme, and someday someone needs to go in
> and fix it. The memory consumption can get to be quite considerable in
> some cases. I suppose that at the same time the over-allocation bug is
> fixed that we also fix the single-lun code to be a lot more bulletproof.
FWIW, I solved the LUN-based changer problem in FreeBSD/CAM by adding a
sort-of scheduler to the CD driver. All CD devices that are part of a
changer are grouped together, and commands can only be issued to one LUN
at a time.
There is a minimum time quantum (on the order of seconds) that the kernel
guarantees that will be given to each LUN, and a maximum amount of time
that will be spent on a given LUN if any I/O is pending for another LUN on
the changer.
I found that for some devices, if you switch back and forth between CDs too
fast, the firmware craps out and won't respond. So that's why there is a
minimum time quantum. (The default is 5 seconds.)
Ken
--
Kenneth Merry
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
