All of lore.kernel.org
 help / color / mirror / Atom feed
From: Douglas Gilbert <dougg@torque.net>
To: James Bottomley <James.Bottomley@SteelEye.com>
Cc: Hannes Reinecke <hare@suse.de>,
	SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH/RFC] Allowing REQ_FAILFAST to be set from SG_IO
Date: Wed, 10 May 2006 13:42:49 -0400	[thread overview]
Message-ID: <44622619.4020805@torque.net> (raw)
In-Reply-To: <1147279812.3671.8.camel@mulgrave.il.steeleye.com>

James Bottomley wrote:
> On Wed, 2006-05-10 at 12:41 -0400, Douglas Gilbert wrote:
> 
>>Looks good. There is no proposed change to sg.c .
>>Could SG_FLAG_FAILFAST be made to work via sg device
>>nodes?
> 
> 
> Rather than having to maintain two separate paths for SG_IO and hence
> keep running into this issue, what will it take for sg to use the block
> scsi_ioctl.c?

Methinks a large amount of code and a lot of testing.
Hannes is proposing a new SG_FLAG value that would
only be active in the block layer SG_IO. The existing
SG_FLAG values are only implemented by the sg driver.
Around that level in the sg driver, the command
injection and response processing are asynchronous
and that can be exposed to the sg user. The block
SG_IO is synchronous with no easy way to break
it down to its component parts.

On further thought if anything in the scsi midlayer
(or the block layer) is slowing down an error report
getting back to a sg user then that is most likely a
bug. The sg driver sends commands with retries set to
zero. Also settings in the read/write error recovery
mode page can effect how long a disk (or cd/drive)
spends trying to recovery from errors (and
SG_FLAG_FASTFAIL has no effect at the device (lu)
end).

Doug Gilbert


  reply	other threads:[~2006-05-10 17:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-10 13:51 [PATCH/RFC] Allowing REQ_FAILFAST to be set from SG_IO Hannes Reinecke
2006-05-10 16:41 ` Douglas Gilbert
2006-05-10 16:50   ` James Bottomley
2006-05-10 17:42     ` Douglas Gilbert [this message]
2006-05-11 10:39       ` Hannes Reinecke
2006-05-11 10:36     ` Jens Axboe
2006-05-11 10:28   ` Hannes Reinecke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44622619.4020805@torque.net \
    --to=dougg@torque.net \
    --cc=James.Bottomley@SteelEye.com \
    --cc=hare@suse.de \
    --cc=linux-scsi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.