All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bernd Schubert <bs_lists@aakef.fastmail.fm>
To: "Desai, Kashyap" <Kashyap.Desai@lsi.com>
Cc: James Bottomley <James.Bottomley@suse.de>,
	Mike Christie <michaelc@cs.wisc.edu>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Subject: [PATCH] Re: SYNCHRONIZE_CACHE from sd_preppare_flush does not have retries.!
Date: Tue, 20 Apr 2010 16:54:04 +0200	[thread overview]
Message-ID: <201004201654.04934.bs_lists@aakef.fastmail.fm> (raw)
In-Reply-To: <1C9608B8A4CD534FB19C7C7543CBB249021C7719CF@inbmail02.lsi.com>

On Tuesday 20 April 2010, Desai, Kashyap wrote:
> > > > > all block device flushes or is this more device specific? I was
> > > > > thinking that we may want to create a sysfs interface under the
> >
> > block
> >
> > > > > dirs and have blk-sysfs.c and blk-barrier.c handle this.
> >
> > queue_flush
> >
> > > > > could set the timeout and retries that is set by some new files
> >
> > under
> >
> > > > > /sys/block/sdX/queue/ ?
> 
> Thanks a lot for your comments.
> 
> This is very close to my understanding. I feel this is more close to block
>  layer and I am almost agreeing with your thought. I tried to understand
>  why upstream does not have retries at queue_flush()/sd_prepare_flush() ???
>  It looks like there is not specific reason. If I am wrong can someone
>  explain is there any specific reason not to set rq->retries in
>  sd_prepare_flush?

I don't understand why we should need another queue timeout, when we 
already have a device timeout that is used as queue timeout?
Below is an updated patch. And I think as of commit 
242f9dcb8ba6f68fcd217a119a7648a4f69290e9 ("block: unify request 
timeout handling") using struct request_queue->rq_timeout is correct.

What I really wonder about, if we shouldn't add a scsi sysfs entry 
to set a default timeout? In some environments (e.g. ib_srp with a 
large number of LUNs through an IB switch) scanning the those devices 
can be slow and besides that many of those device scan functions 
use SD_TIMEOUT, we also have not set timeouts using udev already, 
as udev will only be called once the scan is over...



[SCSI] Use user defined timeouts for SYNCHRONIZE_CACHE

Switch to adjustable timeout value for scsi SYNCHRONIZE_CACHE commands.
We have been running into problems with fixed values on troublesome devices.

Update: add SD_MAX_RETRIES in sd_prepare_flush()

Patch originally written for Q-Leap, but DDN needs it as well.


Signed-off-by: Bernd Schubert <bschubert@ddn.com>


---
 drivers/scsi/sd.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

Index: linux-git/drivers/scsi/sd.c
===================================================================
--- linux-git.orig/drivers/scsi/sd.c
+++ linux-git/drivers/scsi/sd.c
@@ -1020,7 +1020,8 @@ static int sd_sync_cache(struct scsi_dis
 		 * flush everything.
 		 */
 		res = scsi_execute_req(sdp, cmd, DMA_NONE, NULL, 0, &sshdr,
-				       SD_TIMEOUT, SD_MAX_RETRIES, NULL);
+				       sdp->request_queue->rq_timeout,
+				       SD_MAX_RETRIES, NULL);
 		if (res == 0)
 			break;
 	}
@@ -1039,7 +1040,8 @@ static int sd_sync_cache(struct scsi_dis
 static void sd_prepare_flush(struct request_queue *q, struct request *rq)
 {
 	rq->cmd_type = REQ_TYPE_BLOCK_PC;
-	rq->timeout = SD_TIMEOUT;
+	rq->timeout = q->rq_timeout;
+	rq->retries = SD_MAX_RETRIES;
 	rq->cmd[0] = SYNCHRONIZE_CACHE;
 	rq->cmd_len = 10;
 }


  reply	other threads:[~2010-04-20 14:54 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-19 11:32 SYNCHRONIZE_CACHE from sd_preppare_flush does not have retries.! Desai, Kashyap
2010-04-19 16:20 ` Mike Christie
2010-04-19 18:14   ` Bernd Schubert
2010-04-19 18:45     ` James Bottomley
2010-04-19 19:17       ` Bernd Schubert
2010-04-20  5:05         ` Desai, Kashyap
2010-04-20 14:54           ` Bernd Schubert [this message]
2010-04-20 19:32             ` [PATCH] " Mike Christie
2010-04-20 20:38               ` Bernd Schubert
2010-04-22 16:23                 ` James Bottomley
2010-04-29 20:13       ` Ric Wheeler

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=201004201654.04934.bs_lists@aakef.fastmail.fm \
    --to=bs_lists@aakef.fastmail.fm \
    --cc=James.Bottomley@suse.de \
    --cc=Kashyap.Desai@lsi.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=michaelc@cs.wisc.edu \
    /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.