Re: [Patch] dont block device on QUEUE_FULL for last command

Re: [Patch] dont block device on QUEUE_FULL for last command

[Andreas Herrmann]

        Jeff Garzik <jgarzik@pobox.com>
        08/04/03 05:48 PM
 
> On Mon, Aug 04, 2003 at 05:42:51PM +0200, Andreas Herrmann wrote:
> > Hi,
> > 
> > I observed the following problem:
> > A device was marked as blocked after a QUEUE_FULL status code
> > was returned for the last scsi command for a device.
> > And there's a snag to it -- because no further commands are pending
> > for that device, the device is not set unblocked anymore.
> > 
> > Solution is:
> > Do not block the device/adapter if getting QUEUE_FULL status code
> > for the last pending command of that device/adapter, but retry
> > the command.

> For most cases you _should_ block until another command is completed, at
> the very least.  Retrying the command immediately is _exactly_ the
> situation one wishes to avoid, when returning a QUEUE_FULL result!

>    Jeff


        ... until another command is completed ...

... which will never happen, because there was a QUEUE_FULL for the
last command for the device.  The device will be blocked. No further
commands are sent. Bad luck?

OK, retrying seems not to be nice. But better retry than blocking the
device for ever ...

BTW, the condition

                if (cmd->device->device_busy == 0)

is never met. device_busy is always > 0 if there is at least 1 command.
(Or missed I something here?)

So, I just assume: The intention of the writer of the original code was
exactly what I proposed with the patch.


Regards,

Andreas

Re: [Patch] dont block device on QUEUE_FULL for last command

[Jeff Garzik]

Andreas Herrmann wrote:
>         Jeff Garzik <jgarzik@pobox.com>
>>For most cases you _should_ block until another command is completed, at
>>the very least.  Retrying the command immediately is _exactly_ the
>>situation one wishes to avoid, when returning a QUEUE_FULL result!

>         ... until another command is completed ...
> 
> ... which will never happen, because there was a QUEUE_FULL for the
> last command for the device.  The device will be blocked. No further
> commands are sent. Bad luck?

No; if driver does not complete (i.e. error out) commands in a timely 
manner, that's a driver bug.

Thus, the queue should stay blocked until another command is completed, 
because, not completing a command would be wrong :)

	Jeff

Re: [Patch] dont block device on QUEUE_FULL for last command

[Andreas Herrmann]

        James Bottomley <James.Bottomley@SteelEye.com>
        08/04/03 06:05 PM

> On Mon, 2003-08-04 at 10:42, Andreas Herrmann wrote:
> > I observed the following problem:
> > A device was marked as blocked after a QUEUE_FULL status code
> > was returned for the last scsi command for a device.
> > And there's a snag to it -- because no further commands are pending
> > for that device, the device is not set unblocked anymore.
> > 
> > Solution is:
> > Do not block the device/adapter if getting QUEUE_FULL status code
> > for the last pending command of that device/adapter, but retry
> > the command.

> This looks like 2.4 code, right?

Right, the patch is against 2.4.21

> The problem was fixed long ago in 2.5.

> The fix you propose for 2.4 isn't optimal (although it is what 2.4 does
> for the busy case) because the mid-layer will bang the drive in a tight
> loop until it can accept the command.

The fix is short.
It works.
Has no severe side effects. (except the loop until the command is
accepted.)

> You could try backporting the 2.5 fix.  What we do there is to plug the
> queue and then count down (from 7 for host busy or 3 from device busy)
> replugging each time.  That gives a non-busy delay which is directly
> proportional to the I/O pressure in the system.

I could try, if I had time ... ;-)
But why backporting, if a "two-line-changing" patch will fix something,
that looks somehow strange in any case?
IMHO, the condition

                if (cmd->device->device_busy == 0)

is never met in scsi_mlqueue_insert(), because device_busy (same with
host_busy) is always > 0 if there is a command pending for a device 
(host).

> James


Regards,

Andreas

[Patch] dont block device on QUEUE_FULL for last command

[Andreas Herrmann]

Hi,

I observed the following problem:
A device was marked as blocked after a QUEUE_FULL status code
was returned for the last scsi command for a device.
And there's a snag to it -- because no further commands are pending
for that device, the device is not set unblocked anymore.

Solution is:
Do not block the device/adapter if getting QUEUE_FULL status code
for the last pending command of that device/adapter, but retry
the command.


Regards,

Andreas


Here is a patch for drivers/scsi/scsi_queue.c

--- scsi_queue.c        Mon Aug  4 16:22:16 2003
+++ scsi_queue.c.new    Mon Aug  4 16:23:49 2003
@@ -103,7 +103,7 @@
                 * If a host is inactive and cannot queue any commands, I 
don't see
                 * how things could possibly work anyways.
                 */
-               if (host->host_busy == 0) {
+               if (host->host_busy == 1) {
                        if (scsi_retry_command(cmd) == 0) {
                                return 0;
                        }
@@ -118,7 +118,7 @@
                 * If a host is inactive and cannot queue any commands, I 
don't see
                 * how things could possibly work anyways.
                 */
-               if (cmd->device->device_busy == 0) {
+               if (cmd->device->device_busy == 1) {
                        if (scsi_retry_command(cmd) == 0) {
                                return 0;
                        }

Re: [Patch] dont block device on QUEUE_FULL for last command

[Jeff Garzik]

On Mon, Aug 04, 2003 at 05:42:51PM +0200, Andreas Herrmann wrote:
> Hi,
> 
> I observed the following problem:
> A device was marked as blocked after a QUEUE_FULL status code
> was returned for the last scsi command for a device.
> And there's a snag to it -- because no further commands are pending
> for that device, the device is not set unblocked anymore.
> 
> Solution is:
> Do not block the device/adapter if getting QUEUE_FULL status code
> for the last pending command of that device/adapter, but retry
> the command.

For most cases you _should_ block until another command is completed, at
the very least.  Retrying the command immediately is _exactly_ the
situation one wishes to avoid, when returning a QUEUE_FULL result!

	Jeff

Re: [Patch] dont block device on QUEUE_FULL for last command

[Jens Axboe]

On Mon, Aug 04 2003, Jeff Garzik wrote:
> For most cases you _should_ block until another command is completed, at
> the very least.  Retrying the command immediately is _exactly_ the
> situation one wishes to avoid, when returning a QUEUE_FULL result!

Depends very much on who you ask :-)

-- 
Jens Axboe

Re: [Patch] dont block device on QUEUE_FULL for last command

[Kurt Garloff]

[-- Attachment #1: Type: text/plain, Size: 700 bytes --]

On Tue, Aug 05, 2003 at 08:07:45AM +0200, Jens Axboe wrote:
> On Mon, Aug 04 2003, Jeff Garzik wrote:
> > For most cases you _should_ block until another command is completed, at
> > the very least.  Retrying the command immediately is _exactly_ the
> > situation one wishes to avoid, when returning a QUEUE_FULL result!
> 
> Depends very much on who you ask :-)

If there's no more commands, you would wait forever.
The patch is correct and needed IMVHO.

Regards,
-- 
Kurt Garloff  <garloff@suse.de>                            Cologne, DE 
GPG key: See mail header, key servers                 SuSE Labs (Head)
SuSE Linux AG, Nuernberg, DE                            SCSI, Security

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Patch] dont block device on QUEUE_FULL for last command

[James Bottomley]

On Mon, 2003-08-04 at 10:42, Andreas Herrmann wrote:
> I observed the following problem:
> A device was marked as blocked after a QUEUE_FULL status code
> was returned for the last scsi command for a device.
> And there's a snag to it -- because no further commands are pending
> for that device, the device is not set unblocked anymore.
> 
> Solution is:
> Do not block the device/adapter if getting QUEUE_FULL status code
> for the last pending command of that device/adapter, but retry
> the command.

This looks like 2.4 code, right?

The problem was fixed long ago in 2.5.

The fix you propose for 2.4 isn't optimal (although it is what 2.4 does
for the busy case) because the mid-layer will bang the drive in a tight
loop until it can accept the command.

You could try backporting the 2.5 fix.  What we do there is to plug the
queue and then count down (from 7 for host busy or 3 from device busy)
replugging each time.  That gives a non-busy delay which is directly
proportional to the I/O pressure in the system.

James