On Fri, 7 May 1999, Doug Ledford wrote:
> "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
This will not make difference about having to waste either time or
BUS bandwitch. The only thing that can make difference is the device
reserving at least 1 queue entry for each initiator. But that is
ideal situation that requires the device to keep track of each
initiator that has ever talked to it.
> 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.
This few variance demonstrate that we cannot behave differently on
these 2 different statuses.
> > > 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.
If you would got a BUSY status instead, you would be equally stuck.
> > > > 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).
By the way, differentiation is great. ;-)
The heuristic I use is dynamic and ensure that less than 0.1 % QUEUE
FULL's will be got in average, even with Quantum drives.
The 0.1% is hardcoded, but something more aggessive that only will
be happy with 1% should not affect performances to much.
By the way, hard disks that return BUSY status after initialisation
often enough to require some sophisticated heuristic in order not to
affect significantly performances are not supported by the
drivers I maintain. ;-)
Regards,
G�rard.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
