All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Mike Christie <mikenc@us.ibm.com>
Cc: James Bottomley <James.Bottomley@steeleye.com>,
	Masao Fukuchi <fukuchi.masao@jp.fujitsu.com>,
	SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH] improvement of fastfail operation
Date: Thu, 1 Apr 2004 00:04:17 +0200	[thread overview]
Message-ID: <20040331220416.GQ24370@suse.de> (raw)
In-Reply-To: <Pine.LNX.4.44.0403302108550.7851-200000@dyn319701.beaverton.ibm.com>

On Tue, Mar 30 2004, Mike Christie wrote:
> On 30 Mar 2004, James Bottomley wrote:
> 
> > On Mon, 2004-03-29 at 07:17, Masao Fukuchi wrote:
> > > By the way, how about item 1.
> > > I think this is bug and we need to validate fastfail for command timeout.
> > > If you agree with this, please put it into official patch.
> > > (See attached patch)
> > 
> > Well, the patch doesn't apply, but I put an equivalent in the tree.
> > 
> > > Next, I tested the fastfail recovery using Kernel 2.6.4.
> > > But the command didn't complete forever.
> > > Then I installed following Mike Christie's patch and it worked fine.
> > >  http://marc.theaimsgroup.com/?l=linux-scsi&m=107904932710899&w=2
> > > Please put it into official patch.
> > 
> > This patch is obviously wrong on its face.  It completes the request
> > without regard to any leftovers.
> > 
> > There's clearly a problem somewhere in the completion path for commands
> > that run out of retries, but whatever it is, this patch only covers it
> > up it doesn't solve the root problem.
> > 
> 
> This patch
> http://marc.theaimsgroup.com/?l=linux-scsi&m=107904932710899&w=2
> is correct wrt how the block layer uses hard_nr_sectors ;)
> 
> The blkdev.h comments state that hard_nr_sectors is the number
> of sectors left to be completed. This is managed by the block layer
> for drivers like SCSI when end_that_request_* calls
> __end_that_request_first which for partial completions calls
> blk_recalc_rq_sectors. This function updates hard_nr_sectors
> by the completed number of bytes, so by scsi_end_request doing this:
> 
>  if (end_that_request_chunk(req, uptodate, bytes)) {
>         int leftover = (req->hard_nr_sectors << 9) - bytes;
> 
> we end up with "bytes" getting subtracted twice and the final
> bio not getting completed.

Yeah, that's the buggy bit. Ater calling end_that_request_chunk(), that
should just read

	int leftover = req->hard_nr_sectors << 9;

which iirc is what your patch did, it was correct.

> I know we went through that already. It is just to update
> Masao/linux-scsi.
> 
> I had sent the attached patch to Jens (cc'd him)
> that modifies how blk_recalc_rq_sectors uses hard_nr_sectors,
> but I think it might break some other drivers that expect the
> hard_nr_sectors to be updated as the request is completed.

Yeah that doesn't work... hard_* values are really just to make sure
that the non-hard values are sane after block driver messes with the
other ones. So consider hard_* internal block stuff.

So the new patch you sent with this mail is no good. Your previous one
should be adopted ;-)

-- 
Jens Axboe


  reply	other threads:[~2004-03-31 22:05 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-24  0:38 [PATCH] improvement of fastfail operation Masao Fukuchi
2004-03-27 15:57 ` James Bottomley
2004-03-29 10:20   ` Mike Christie
2004-03-29 12:17   ` Masao Fukuchi
2004-03-31  1:29     ` James Bottomley
2004-03-31  5:14       ` Mike Christie
2004-03-31 22:04         ` Jens Axboe [this message]
2004-03-31 22:11           ` James Bottomley
2004-03-31 22:12             ` Jens Axboe
2004-03-31 23:15               ` Mike Christie
2004-04-01  6:47                 ` Jens Axboe
     [not found]                 ` <406BC50E.6090100@us.ibm.com>
2004-04-01  7:53                   ` Mike Christie
2004-04-01 15:06                     ` James Bottomley

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=20040331220416.GQ24370@suse.de \
    --to=axboe@suse.de \
    --cc=James.Bottomley@steeleye.com \
    --cc=fukuchi.masao@jp.fujitsu.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mikenc@us.ibm.com \
    /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.