From: Andrew Morton <akpm@linux-foundation.org>
To: Mark Lord <liml@rtr.ca>
Cc: Norman Diamond <n0diamond@yahoo.co.jp>,
linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org
Subject: Re: Overagressive failing of disk reads, both LIBATA and IDE
Date: Fri, 20 Mar 2009 03:00:12 -0700 [thread overview]
Message-ID: <20090320030012.2f19f709.akpm@linux-foundation.org> (raw)
In-Reply-To: <49C30E67.4060702@rtr.ca>
On Thu, 19 Mar 2009 23:32:55 -0400 Mark Lord <liml@rtr.ca> wrote:
> Norman Diamond wrote:
> > For months I was wondering how a disk could do this:
> > dd if=/dev/hda of=/dev/null bs=512 skip=551540 count=4 # succeeds
> > dd if=/dev/hda of=/dev/null bs=512 skip=551544 count=4 # succeeds
> > dd if=/dev/hda of=/dev/null bs=512 skip=551540 count=8 # fails
> >
> > It turns out the disk isn't doing that. Linux is. The old IDE drivers did
> > it, but with LIBATA the same thing happens to /dev/sda. In later examples
> > also, the same happens to /dev/sda as /dev/hda.
> ..
>
> You can blame me for the IDE driver not doing that properly.
> But for libata, it's the SCSI layer.
>
> I've been patching this for years for my clients,
> and will be updating the patch soon-ish and trying
> again to get it into upstream kernels.
>
> Here's the (now ancient) 2.6.20 version for SLES10:
>
> * * *
>
> Allow SCSI to continue with the remaining blocks of a request
> after encountering a media error. Otherwise, it may just fail
> the entire request, even though some blocks were fine and needed
> by a completely different process than the one that wanted the bad block(s).
>
> Signed-off-by: Mark Lord <mlord@pobox.com>
>
> --- linux-2.6.16.60-0.6/drivers/scsi/scsi_lib.c 2008-03-10 13:46:03.000000000 -0400
> +++ linux/drivers/scsi/scsi_lib.c 2008-03-21 11:54:09.000000000 -0400
> @@ -888,6 +888,12 @@
> */
> if (sense_valid && !sense_deferred) {
> switch (sshdr.sense_key) {
> + case MEDIUM_ERROR:
> + /* Bad sector. Fail it, and then continue the rest of the request. */
> + if (scsi_end_request(cmd, 0, cmd->device->sector_size, 1) == NULL) {
> + cmd->retries = 0; // go around again..
> + return;
> + }
> case UNIT_ATTENTION:
> if (cmd->device->removable) {
> /* Detected disc change. Set a bit
Once upon a time the VFS would fall back to single page reads when a large
readahead request failed. That's probably still the case.
It was more by accident than by design, but it had (has) the desired effect?
next prev parent reply other threads:[~2009-03-20 10:06 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-20 2:12 Overagressive failing of disk reads, both LIBATA and IDE Norman Diamond
2009-03-20 3:32 ` Mark Lord
2009-03-20 10:00 ` Andrew Morton [this message]
2009-03-20 13:09 ` Mark Lord
2009-03-21 14:22 ` James Bottomley
2009-03-21 14:55 ` Mark Lord
2009-03-21 15:01 ` Mark Lord
2009-03-21 15:08 ` James Bottomley
2009-03-21 15:20 ` Mark Lord
2009-03-21 15:10 ` Alan Cox
2009-03-21 15:18 ` James Bottomley
2009-03-22 2:15 ` Norman Diamond
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=20090320030012.2f19f709.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=liml@rtr.ca \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=n0diamond@yahoo.co.jp \
/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).