linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Norman Diamond" <ndiamond@wta.att.ne.jp>
To: "Mudama, Eric" <eric_mudama@Maxtor.com>,
	"'Hans Reiser '" <reiser@namesys.com>,
	"'Wes Janzen '" <superchkn@sbcglobal.net>,
	"'Rogier Wolff '" <R.E.Wolff@BitWizard.nl>,
	"'John Bradford '" <john@grabjohn.com>,
	<linux-kernel@vger.kernel.org>, <nikita@namesys.com>,
	"'Pavel Machek '" <pavel@ucw.cz>,
	"'Justin Cormack '" <justin@street-vision.com>,
	"'Russell King '" <rmk+lkml@arm.linux.org.uk>,
	"'Vitaly Fertman '" <vitaly@namesys.com>,
	"'Krzysztof Halasa '" <khc@pm.waw.pl>
Subject: Re: Blockbusting news, results get worse
Date: Sun, 26 Oct 2003 16:37:10 +0900	[thread overview]
Message-ID: <334101c39b94$268a0370$24ee4ca5@DIAMONDLX60> (raw)

It gets worse.  First, to recap previous results:

1.  The drive reported a permanent error on read, refused to reallocate the
bad sector, and Linux logged the error but refused to remove the block from
the Reiser file system.  (Different people have different opinions about
whether various parts of this behavior are acceptable, but anyway this was
one of the observed results.)

2.  The drive reported a permanent error on write, refused to reallocate the
bad sector, and Linux logged the error but refused to remove the block from
the Reiser file system.  (I'm not sure if different people have different
opinions about whether various parts of this behavior are acceptable.  This
was a write, good data were known at the time, but subsequently good data
would never be retrievable from the file.)

3.  The drive reported a permanent read error during a S.M.A.R.T. long
self-test and refused to reallocate the bad sector.  (I think different
people have different opinions about the acceptability of this too.)

Well, here's news.

4.  When writing ZEROES to the bad sector, the drive reports SUCCESS.
But it lies.  Subsequent attempts to read still fail.  Subsequent writing of
zeroes appears to succeed again.  Subsequent attempts to read still fail.

I swear, I want that block out of the file system.  Even if the writing of
zeroes really succeeded, I would not be satisfied with the continued use of
that block.  I really want the drive to reallocate it, but Toshiba's
firmware is unsafe to drive at any speed.  So I really want the file system
to exclude that block.

Some participants in this discussion have said that ext2fs can exclude bad
blocks in a way that ReiserFS doesn't, though ReiserFS probably will in the
future.  But to the best of my understanding, ext2fs can detect and exclude
bad blocks at the time of formatting and at the time of a destructive
read-write test.  I have not seen news from anyone about whether ext2fs will
remove a detected permanent bad block from an existing mounted filesystem at
the time that the error is detected during normal operations.  It is 99%
necessary to do so (leaving 1% for audio visual applications where it's more
important to play a movie erroneously at proper speed than to attempt
recovery).

By the way, one participant in this thread recommended not buying disk
drives from bargain basement outlets.  OK, yesterday I inquired at Bic
Camera, which might be one of the biggest two retailers of computers and
parts nationwide, but might not be because they don't have many stores
outside of the Tokyo area.  At least they're surely one of the two biggest
in Tokyo.  They said that they warranty Toshiba disk drives for 1 year.  So
if a customer buys a Toshiba disk drive with firmware that was defective on
the day of purchase and defective on the dates of design and manufacture,
but if the customer doesn't detect the defective firmware until 366 days
later, the customer still gets shafted.

I still have to say, we can't fix Toshiba, and we can avoid Toshiba, but
meanwhile we can fix Linux.  Among other manufacturers, only Maxtor has said
that their firmware isn't broken in this way, but Maxtor doesn't make drives
for notebooks.  Just how many manufacturers of disk drives are we going to
avoid, or can we hope that Linux will be made to compensate for their
defects?

Well, in a future weekend, I will try to see if ext2fs really takes action
on permanently bad blocks that are detected during normal operations on a
mounted partition.


             reply	other threads:[~2003-10-26  7:39 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-26  7:37 Norman Diamond [this message]
2003-10-26 10:39 ` Blockbusting news, results get worse John Bradford
2003-10-26  9:41   ` Pavel Machek
2003-10-26 11:38   ` Norman Diamond
2003-10-26 11:56     ` Pavel Machek
2003-10-26 12:06     ` Hans Reiser
2003-10-26 13:59     ` Krzysztof Halasa
2003-10-26 18:33 Mudama, Eric
2003-10-26 22:03 ` Andre Hedrick
2003-10-27  9:34 ` Norman Diamond
2003-10-27 10:23   ` Jan-Benedict Glaw
2003-10-27 23:31   ` Jason Lunz
2003-10-28 20:56   ` Hans Reiser
2003-10-26 22:12 Mudama, Eric
2003-10-27 13:07 Samium Gromoff
2003-10-27 17:43 Mudama, Eric
2003-10-27 18:48 ` Hans Reiser
2003-10-27 19:47   ` Jeff Garzik
2003-10-27 20:03     ` John Bradford
2003-10-29 20:01       ` Pavel Machek
2003-10-30  8:30         ` John Bradford
2003-10-28  1:21     ` Pavel Machek
2003-10-28 12:54       ` Krzysztof Halasa
2003-10-27 18:06 Mudama, Eric
2003-10-27 19:18 ` Andre Hedrick
2003-10-29 20:11 Mudama, Eric

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='334101c39b94$268a0370$24ee4ca5@DIAMONDLX60' \
    --to=ndiamond@wta.att.ne.jp \
    --cc=R.E.Wolff@BitWizard.nl \
    --cc=eric_mudama@Maxtor.com \
    --cc=john@grabjohn.com \
    --cc=justin@street-vision.com \
    --cc=khc@pm.waw.pl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nikita@namesys.com \
    --cc=pavel@ucw.cz \
    --cc=reiser@namesys.com \
    --cc=rmk+lkml@arm.linux.org.uk \
    --cc=superchkn@sbcglobal.net \
    --cc=vitaly@namesys.com \
    /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).