From: Mark Lord <lkml@rtr.ca>
To: Andrew Morton <akpm@osdl.org>
Cc: James Bottomley <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: Wed, 26 Apr 2006 19:20:19 -0400 [thread overview]
Message-ID: <44500033.3010605@rtr.ca> (raw)
In-Reply-To: <20060426161444.423a8296.akpm@osdl.org>
Andrew Morton wrote:
>
> It'd be nice to have something simple-and-obvious for the
> simple-and-obvious -stable maintainers.
That's why I kept the original patch very simple and focused,
rather than trying to fix all of the convoluted code around it.
It's nice and simple, and *looks* correct.
A longer term cleanup of that function is better left to James!
> 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.
Better, but still not the best.
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.
I'm thinking about something like that, just not sure whether to put it
(initially) in libata, sd.c, or the block layer.
Cheers
next prev parent reply other threads:[~2006-04-26 23:20 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 [this message]
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
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=44500033.3010605@rtr.ca \
--to=lkml@rtr.ca \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox