Linux ATA/IDE development
 help / color / mirror / Atom feed
From: "Norman Diamond" <n0diamond@yahoo.co.jp>
To: linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org
Subject: Overagressive failing of disk reads, both LIBATA and IDE
Date: Fri, 20 Mar 2009 11:12:11 +0900	[thread overview]
Message-ID: <F79C774361EF45A6A68BC08F8621E406@DIAMOND8600> (raw)

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.

Here's what the disk is really responsible for:
dd if=/dev/hda of=/dev/null bs=512 skip=551562 count=1  # really fails

Here's Linux to blame again:
dd if=/dev/hda of=/dev/null bs=512 skip=551561 count=1  # fails

When the drive reports an uncorrectable media error, Linux correctly records
it in the log.  But when the app didn't ask for that block, when blocks that
the app asked for were all read, Linux incorrectly reports failure to the
app.

I don't know how Linux decides how many blocks to read ahead, but no matter
how many it chooses, read ahead is read ahead.  Go ahead and record it in
the log.  I'd also like to suggest that if a user is logged in on the screen
(whether X11 or text) see if we can warn them that their disk is dying.  But
don't return a failure to the app.  If the blocks that the app asked for
were read, we should give them to the app, successfully.

Sheesh.

P.S.
One would expect this to persuade the hard drive to relocate the block:
dd if=/dev/zero of=/dev/hda bs=512 seek=551562 count=1
But it doesn't because Linux wants to read 4 blocks, modify 1, and write 4
blocks.  The read fails.

One would expect this to persuade the hard drive to relocate the block:
dd if=/dev/zero of=/dev/hda bs=512 seek=551560 count=4
But it doesn't because the hard drive reports success.  If an app tries to
read the bad sector again it still fails.  So the drive has egregiously bad
firmware.  That doesn't excuse Linux.

--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

             reply	other threads:[~2009-03-20  3:20 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-20  2:12 Norman Diamond [this message]
2009-03-20  3:32 ` Overagressive failing of disk reads, both LIBATA and IDE 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
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=F79C774361EF45A6A68BC08F8621E406@DIAMOND8600 \
    --to=n0diamond@yahoo.co.jp \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@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