"Kenneth D. Merry" wrote:
> And you're right, with write caching disabled, I didn't get any QUEUE FULL
> responses. (The maximum number of transactions for that drive is set to
> 32, so presumably the drive can handle at least that.)
32 is the hard limit according to Quantum.
> Well, for FreeBSD we've got "softupdates", which is essentially asychronous
> filesystem metadata updates. If softupdates are enabled, enabling write
> caching on a drive won't really make any difference, and can make
> performance a little more uneven.
>
> If softupdates aren't enabled, though, enabling write caching on a drive
> generally yields higher performance on random I/O especially.
>
> > > Well, the main bug in LYK8 is the same bug that most every high-end Quantum
> > > drive has nowadays. It continually returns Queue Full under high load, even
> > > when there are very few transactions queued to the drive.
> >
> > This is not a bug, in my opinion and conforms to SCSI specifications.
>
> It may conform to the SCSI specs, but it is annoying.
It's annoying becuase it's stupid. Whether it conforms to the letter of the
SCSI spec or not, it's still stupid. It would be *much* easier if firmware
authors thought about these things before they used QUEUE_FULL all over the
place. There are two very similar conditions that are interesting, QUEUE_FULL
and BUSY, and it makes sense to return BUSY when there are 0 commands
disconnected but the drive currently can't take any more commands, but not
nearly so much sense to return QUEUE_FULL even though both are allowed in that
case. If all the drive makers did something along those lines (used
QUEUE_FULL for cases when you had the maximum number of disconnected commands
already and used BUSY for cases where you have anything less than the maximum
number of commands but the device still can't accept any more at just that
time) then things would be much simpler. But they don't, so if you check in
the aic7xxx driver in linux, the QUEUE_FULL and BUSY portion of the interrupt
handler is basically identical for both conditions with only a few variances.
> > The only thing that is questionnable is to return QUEUE FULL with ZERO
> > command disconnected. Such a situation is very painfull to handle from
> > the kernel/driver. It is kind of 'full and empty condition' that cannot be
> > handled without wasting either time or SCSI BUS bandwitch.
> > Anyway, it is still compliant with SCSI specifications.
>
> You're right, it does make things difficult for an operating system to deal
> with when a drive says that it's full and there are no commands oustanding.
> :)
>
> IBM and Seagate disks don't exhibit the same behavior, I wish Quantum would
> follow suit.
Certain of the Quantum drives are so broken in this regard that I've added a
check for QUEUE_FULL with 0 active commands and I unilaterally disable TCQ on
those drives. Such a condition (especially when it happens the first time you
send a tagged command) is so stupid that I'm not bothering to support it.
Those devices can live without TCQ on my driver.
> > > We "fixed" it in FreeBSD by setting a lower bound on the number of
> > > transaction slots (24) for Atlas II and III drives. Without that, we
> > > would automatically reduce the number of slots (or queue depth) to the
> > > system-wide minimum for devices with tagged queueing enabled (2
> > > transactions).
My QUEUE_FULL handler requires that a drive return a QUEUE_FULL error at the
same active command count at least 13 times in a row (I think, it's some
unreasonably large number like that) before it changes the queue depth, and
then it sets the queue depth to whatever that maximum count is. This avoids
the problem with the various Quantum drives and random QUEUE_FULL messages
while reliably picking up devices that have real hard queue depth limits in
their firmware (such as all the Quantum Fireball drives).
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
