From: Hannes Reinecke <hare@suse.de>
To: dougg@torque.net
Cc: James Bottomley <James.Bottomley@SteelEye.com>,
SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH/RFC] Allowing REQ_FAILFAST to be set from SG_IO
Date: Thu, 11 May 2006 12:39:04 +0200 [thread overview]
Message-ID: <44631448.2010508@suse.de> (raw)
In-Reply-To: <44622619.4020805@torque.net>
Douglas Gilbert wrote:
> 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).
That doesn't apply here. The error recovery in scsi_unjam_host() will be
triggered regardless of the retry setting. Setting the retry to zero
will only cause the command _not_ to be retried; if the device still
reports an error condition the error handler will still be invoked.
One might argue that no error recovery is required for sg.c commands as
the user will have full control (up to and including bus / device reset)
so he's responsible to implement his own error recovery. In that case we
should always send command from sg.c down with the failfast flag set.
But that's a different discussion.
Cheers,
Hannes
--
Dr. Hannes Reinecke hare@suse.de
SuSE Linux Products GmbH S390 & zSeries
Maxfeldstraße 5 +49 911 74053 688
90409 Nürnberg http://www.suse.de
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2006-05-11 10:39 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
2006-05-11 10:39 ` Hannes Reinecke [this message]
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=44631448.2010508@suse.de \
--to=hare@suse.de \
--cc=James.Bottomley@SteelEye.com \
--cc=dougg@torque.net \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).