[205] in linux-scsi channel archive
SCSI Reset Functions.
daemon@ATHENA.MIT.EDU (Leonard N. Zubkoff)
Tue May 23 20:48:24 1995
Date: Tue, 23 May 1995 17:12:10 -0700
From: "Leonard N. Zubkoff" <lnz@dandelion.com>
To: eric@aib.com
Cc: linux-scsi@vger.rutgers.edu, drew@boulder.openware.com
In-Reply-To: "Eric Youngdale"'s message of Tue, 23 May 1995 10:16:58 -0400 <9505231016.ZM23750@aib.com>
From: "Eric Youngdale" <eric@aib.com>
Date: Tue, 23 May 1995 10:16:58 -0400
Yes, the bus device reset is known to work with at least some
controllers, so this much should be safe.
Both seem to be safe with respect to the disk devices at any rate. I ran a
test doing a "find / -type f -xdev -exec md5sum {} \; > /tmp/1" first, and then
doing it to a second file while causing Bus Device Resets and a full Host
Adapter and SCSI Bus Reset from another shell. Both files were identical
modulo system log files being updated, so at least none of the disk accesses
failed to complete with the proper results. Both options are still going to
give grief to mounted CD-ROMs and tapes, of course.
No, 3 seems reasonable to me. The basic idea is that you have two
commands tagged together, you avoid a cycle of bus arbitration, and the
second command can start executing much sooner than it would have if tagged
queueing were not enabled.
The reason that the DPT driver does better with 64 CMD/LUN is that
it apparently does command re-ordering with it's own elevator algorithm in
order to improve performance. If your board does not do this, then you
gain nothing by raising CMD/LUN above 2 or 3.
I thought the disk itself can take multiple commands and then do its own
elevator scheduling, if it is handed enough commands by the host adapter.
Any reason why performance should go down the higher CMD/LUN is set above 3? I
haven't investigated yet, but I've been wondering if perhaps the fact that my
test is reading and writing simultaneously causes poorer I/O overlap with
decompression processing if CMD/LUN is higher. I need to try a similar test
where the source and destination are on different drives.
Michael is quite correct in that setting CMD/LUN this high will
lock out tape drives - the solution is quite simple, but I am temporarily
down as my laptop hard drive is dying, and I am waiting for the replacement
to arrive.
True, though as long as the host adapter has CCB slots available internally,
this shouldn't happen. The BusLogic Host Adapters can hold 32 CCBs, so I don't
think this is too likely to become a problem unless I crank CMD/LUN way up.
To me "automatically restarting" means that the board itself
remembers the commands and automatically restarts them. In principle,
your driver could do the same thing, provided that the board itself does
not do this as well.
But doesn't this have the disadvantage over DID_RESET that the levels of the
driver don't get the timeout updated?
Here "automatically restarted" means that the mid level code does
not need to do anything in order for the command to continue executing, but
this is from the perspective of the code that called the low-level reset
function itself. Setting DID_RESET and calling the completion function
is in fact one way of "automatically restarting" the commands is a way of
restarting them. In theory, one could also attempt to requeue them, but
this would be a bit harder, since the DID_RESET approach more or less does
what you need it to do.
I understand now. I've only looked at this from the device driver perspective,
which made this much less apparent.
Leonard
