public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@pobox.com>
To: Chip Salzenberg <chip@pobox.com>
Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>
Subject: Re: Linux 2.6.3-rc3 - IDE DMA errors on Thinkpad A30
Date: Sun, 15 Feb 2004 22:47:37 -0500	[thread overview]
Message-ID: <40303D59.4030605@pobox.com> (raw)
In-Reply-To: <20040216033740.GE3789@perlsupport.com>

Chip Salzenberg wrote:
> Still: I wonder if the occasional bad sector is really that bad.
> Shirley, at the unreal densities of today's drives, the development of
> bad sectors is inevitable?  (Especially in a laptop drive that's
> bounced around in normal use.)

Open argument :)

A lot of smart people will argue that a bad sector every now and again 
occurs, and "I've run my server's disks that way for years."

Other equally smart people argue that modern IDE disks reserve space for 
remapping bad sectors.  If you run out of sectors that the drive is 
willing to silently remap for you, you should toss the disk and buy a 
new one.

There is of course the caveat that it is impossible to avoid the drive 
returning "bad sector", instead of silently remapping, on reads.

Oh, and I just thought of something else.  Current Linux filesystems 
will, on a read error, usually mark it as a bad sector and move on. 
Really, they should attempt to write to the bad sector before 
considering it bad.

As a result, current kernels will AFAICT assume a sector is bad even 
when the drive politely swaps a good sector in place for you.

One for the todo list, I suppose...  a useable workaround for this is 
probably good ole 'e2fsck -c', i.e. badblocks...  That says "check again 
to see if this sector is bad", and -hopefully- will unmark bad blocks 
that were incorrectly marked bad.

	Jeff




  reply	other threads:[~2004-02-16  3:47 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1pliv-6ya-5@gated-at.bofh.it>
2004-02-15 15:22 ` Linux 2.6.3-rc3 - missing IDE hunk from bk4; good or bad? Chip Salzenberg
2004-02-15 15:58   ` Bartlomiej Zolnierkiewicz
2004-02-15 16:34     ` Linux 2.6.3-rc3 - IDE DMA errors on Thinkpad A30 Chip Salzenberg
2004-02-15 17:08       ` Bartlomiej Zolnierkiewicz
2004-02-16  0:55         ` Chip Salzenberg
2004-02-16  2:14           ` Jeff Garzik
2004-02-16  3:37             ` Chip Salzenberg
2004-02-16  3:47               ` Jeff Garzik [this message]
2004-02-16  3:58                 ` Valdis.Kletnieks
2004-02-16  4:09                   ` Jeff Garzik
2004-02-16  4:29                     ` Valdis.Kletnieks
2004-02-16 12:06                     ` Bill Davidsen
2004-02-16  4:08                 ` Chip Salzenberg
2004-02-16  4:24                   ` Bartlomiej Zolnierkiewicz
2004-02-16 19:27                 ` Eric D. Mudama

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=40303D59.4030605@pobox.com \
    --to=jgarzik@pobox.com \
    --cc=B.Zolnierkiewicz@elka.pw.edu.pl \
    --cc=akpm@osdl.org \
    --cc=chip@pobox.com \
    --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