[7673] in linux-scsi channel archive
Re: Multi-LUN CD changer simultaneous access problem.
daemon@ATHENA.MIT.EDU (Kenneth D. Merry)
Mon Dec 13 01:40:11 1999
Date: Sun, 12 Dec 1999 23:29:06 -0700
From: "Kenneth D. Merry" <ken@kdm.org>
To: Eric Youngdale <eric@andante.org>
Cc: ishikawa <ishikawa@yk.rim.or.jp>,
LINUX SCSI <linux-scsi@vger.rutgers.edu>
Message-ID: <19991212232906.A25934@panzer.kdm.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <Pine.LNX.4.10.9912072019130.21621-100000@gwyn.tux.org>; from eric@andante.org on Tue, Dec 07, 1999 at 08:38:07PM -0500
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
ken@kdm.org
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
