From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
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 10:18:22 -0500 [thread overview]
Message-ID: <1237648702.4600.16.camel@localhost.localdomain> (raw)
In-Reply-To: <20090321151028.2ac4101f@lxorguk.ukuu.org.uk>
On Sat, 2009-03-21 at 15:10 +0000, Alan Cox wrote:
> > 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.
OK, so in modern kernels, this is done in the ULD ... specifically for
disks in sd.c:sd_done and for CD/DVD in sr.c:sr_done().
The sr.c one looks crufty in that I don't think it handles descriptor
sense at all, so perhaps it should be updated to match the sd one?
> > 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.
See other email for suggestion how to do this at the block level.
James
next prev parent reply other threads:[~2009-03-21 15:18 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
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 [this message]
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=1237648702.4600.16.camel@localhost.localdomain \
--to=james.bottomley@hansenpartnership.com \
--cc=alan@lxorguk.ukuu.org.uk \
--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).