All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Lord <mlord@pobox.com>
To: Andrew Morton <akpm@osdl.org>
Cc: James.Bottomley@SteelEye.com, linux-scsi@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drivers/scsi/sd.c: fix uninitialized variable in handling medium errors
Date: Thu, 27 Apr 2006 12:03:10 -0400	[thread overview]
Message-ID: <4450EB3E.7000902@pobox.com> (raw)
In-Reply-To: <20060426163536.6f7bff77.akpm@osdl.org>

Andrew Morton wrote:
> Mark Lord <lkml@rtr.ca> wrote:
>>> That's if we think -stable needs this fixed.
>> Let's say a bunch of read bio's get coalesced into a single
>> 200+ sector request.  This then fails on one single bad sector
>> out of the 200+.  Without the patch, there is a very good chance
>> that sd.c will simply fail the entire request, all 200+ sectors.
>>
>> With the patch, it will fail the first block, and then retry
>> the remaining blocks.  And repeat this until something works,
>> or until everything has failed one by one.
> 
> Yowch.  I have the feeling that this'll take our EIO-handling time from
> far-too-long to far-too-long*200.
> 
> I am still traumatised by my recent ten-minute wait for a dodgy DVD to
> become ejectable.
> 
> I don't think -stable needs this, personally.

Perhaps, perhaps not.  The current behaviour is semi *random*, though.
Sometimes it may just fail the entire request (wrong!),
sometimes it may do the (almost as wrong) fail a block at a time
from the beginning, until the bad sector is passed, and then succeed
on the remainder.

Ugh.
>> What I need to have happen when a request is failed due to bad-media,
>> is have it split the request into a sequence of single-block requests
>> that are passed to the LLD one at a time.  The ones with real bad
>> sectors will then be independently failed, and the rest will get done.
>>
>> Much better.  Much more complex.

-- 
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com

  parent reply	other threads:[~2006-04-27 16:03 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-26 20:27 [PATCH] drivers/scsi/sd.c: fix uninitialized variable in handling medium errors Mark Lord
2006-04-26 20:52 ` Mark Lord
2006-04-26 22:56 ` James Bottomley
2006-04-26 23:04   ` Mark Lord
2006-04-26 23:18     ` James Bottomley
2006-04-26 23:28       ` Mark Lord
2006-04-26 23:14   ` Andrew Morton
2006-04-26 23:20     ` Mark Lord
2006-04-26 23:35       ` Andrew Morton
2006-04-27  1:43         ` Mark Lord
2006-04-27  9:28         ` Rogier Wolff
2006-04-27  9:37         ` Avi Kivity
2006-04-27 16:03         ` Mark Lord [this message]
2006-04-26 23:22     ` 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=4450EB3E.7000902@pobox.com \
    --to=mlord@pobox.com \
    --cc=James.Bottomley@SteelEye.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --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.