All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Freemyer <greg.freemyer@gmail.com>
To: IDE/ATA development list <linux-ide@vger.kernel.org>,
	Mark Lord <liml@rtr.ca>
Subject: Re: If I have a single bad sector, how many failed reads should simple dd report?
Date: Fri, 9 Jul 2010 15:04:22 -0400	[thread overview]
Message-ID: <AANLkTimWfp4mLF9DCpxtnnUQsYQ08gXmh491EfhARe1x@mail.gmail.com> (raw)
In-Reply-To: <AANLkTil2Zfhpkq24qrCoHZVx1vlbIPTcDMrZ508yODta@mail.gmail.com>

Adding Mark Lord to CC because hdparm may be part of the problem.

On Thu, Jul 8, 2010 at 1:14 PM, Greg Freemyer <greg.freemyer@gmail.com> wrote:
> All,
>
> I just ran a test against a IDE drive (/dev/sdb) and slightly older
> kernel (2.6.32).
>
> Similar to:
>
> dd if=/dev/sdb of=/dev/null conv=noerror,sync bs=4k
>
> With a good drive it ran fine.
>
> Then I used hdparm --make-bad-sector to intentionally corrupt a sector
> on the drive.
>
> When I re-ran it, /var/log/messages reported 10 bad logical blocks.
> And even worse, dd reported 20 bad blocks.  I examined the data dd
> read and it had 80KB of zero'ed out data.  So that's 160 sectors worth
> of data lost because of a single bad sector.  At most I was expecting
> 4KB of zero'ed out data.
>
> I haven't started troubleshooting, but I want to know if this is
> expected behavior due to read-ahead or something.  (Is there
> read-ahead on the raw device, or just if a file system is involved.)
>
> I can redo my test with 2.6.34 and get logs if that is a bug.
>
> And if not a bug, is there a hdparm command I can issue to eliminate
> this behaviour.
>
> Thanks
> Greg

I retested with 2.6.25 and see the same behavior, so if its a bug, its
not a recently introduced one.  But 2.6.25 is showing a lot more media
errors than I recall from 2.6.32.

Even stranger, I'm now introducing the bad sector as sector 100,000
(ie. about 50 MB from the start of the drive).

Then doing a dd to capture just the first 100 MB to a file.

ie.
dd if=/dev/sdb of=clean.dd conv=noerror,sync bs=4K count=25600
hdparm --make-bad-sector 100000 --yes-i-know-what-i-am-doing /dev/sdb
dd if=/dev/sdb of=corrupt.dd conv=noerror,sync bs=4K count=25600
hdparm --write-sector 100000 --yes-i-know-what-i-am-doing /dev/sdb

(clearly don't do that to a disk you care about.  The data at sector
100,000 is permanently lost.)

cmp -bl clean.dd corrupt.dd > delta.log

Looking at delta.log, the bytes start disagreeing 4 bytes prior to the
sector boundary.  How can that be?

I guess hdparm --make-bad-sector may be corrupting an extra 4 bytes,
but that would surprise me.

That seems like a definite bug in either the kernel or hdparm.

Mark, do you have any input about either the early start of the
corruption, or the very large number of sectors that seem corrupted by
making a single sector bad.

Greg

  reply	other threads:[~2010-07-09 19:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-08 17:14 If I have a single bad sector, how many failed reads should simple dd report? Greg Freemyer
2010-07-09 19:04 ` Greg Freemyer [this message]
2010-07-10  1:19   ` Mark Lord
2010-07-10  1:24     ` Mark Lord
2010-07-10 14:14       ` James Bottomley
2010-07-11 12:58         ` Greg Freemyer
2010-07-13 19:07         ` Mark Lord

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=AANLkTimWfp4mLF9DCpxtnnUQsYQ08gXmh491EfhARe1x@mail.gmail.com \
    --to=greg.freemyer@gmail.com \
    --cc=liml@rtr.ca \
    --cc=linux-ide@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.