mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Mark Lord <liml@rtr.ca>, 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: Sat, 21 Mar 2009 15:10:28 +0000	[thread overview]
Message-ID: <20090321151028.2ac4101f@lxorguk.ukuu.org.uk> (raw)
In-Reply-To: <1237645333.4600.9.camel@localhost.localdomain>

> Using the disk supplied data about where the error occurred (provided
> the disk returns it) eliminates all the readahead problems like the one

ATA disks do provide sector information generally, as do CD-ROMs, in fact
we actually decode it for error reporting so probably all the bits are
there to improve any reporting for most read side cases.

>From some of the traces I have been debugging I am not convinced the scsi
mid layer does the right thing any more. It uses to be handling CD-R
media (where the end of media is not well defined) but nowdays seems to
be reporting errors even when told that the I/O partly succeeded. I need
to debug that case further however but as I don't have one of the problem
drives its a bit tricky.

> above.  Perhaps just turning of readahead for disks that don't supply
> error location information would be a reasonable workaround?

Not really. From a performance perspective Mark's patch is vastly
superior because it punishes the incredibly rare error case not the
routine working performance. Avoiding the need to do either would be even
better - as would fixing the block layer not to mess up retries in this
situation.

For low speed devices like MMC cards and flash it might make sense not to
merge unrelated requests however so that only the relevant one fails.

Alan

  parent reply	other threads:[~2009-03-21 15:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-20  2:12 Norman Diamond
2009-03-20  3:32 ` Mark Lord
2009-03-20 10:00   ` Andrew Morton
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 [this message]
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=20090321151028.2ac4101f@lxorguk.ukuu.org.uk \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=James.Bottomley@HansenPartnership.com \
    --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

all inboxes | Powered by JetHome®