From: "Norman Diamond" <ndiamond@wta.att.ne.jp>
To: "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>
Subject: Blockbusting news, this is important (Re: Why are bad disk sectors numbered strangely, and what happens to them?)
Date: Fri, 17 Oct 2003 18:40:01 +0900 [thread overview]
Message-ID: <11bf01c39492$bc5307c0$3eee4ca5@DIAMONDLX60> (raw)
In-Reply-To: 3F8BBC08.6030901@namesys.com
Friends in the disk drive section at Toshiba said this:
When a drive tries to read a block, if it detects errors, it retries up to
255 times. If a retry succeeds then the block gets reallocated. IF 255
RETRIES FAIL THEN THE BLOCK DOES NOT GET REALLOCATED.
This was so unbelievable to that I had to confirm this with them in
different words. In case of a temporary error, the drive provides the
recovered data as the result of the read operation and the drive writes the
data to a reallocated sector. In case of a permanent error, the block is
assumed bad, and of course the data are lost. Since the data are assumed
lost, the drive keeps the defective LBA sector number associated with the
same defective physical block and it does not reallocate the defective
block.
I explained to them why the LBA sector number should still get reallocated
even though the data are lost. When the sector isn't reallocated, I could
repartition the drive and reformat the partition and the OS wouldn't know
about the defective block so the OS would try again to use it. At first
they did not believe I could do this, but I explained to them that I'm still
able to delete partitions and create new partitions etc., and then they
understood.
They also said that a write operation has a chance of getting the bad block
reallocated. The conditions for reallocation on write are similar but not
identical to the conditions for reallocate on read. During a write
operation if a sector is determined to be permanently bad (255 failing
retries) then it is likely to be reallocated, unlike a read. But I'm not
sure if this is guaranteed or not. We agreed that we should try it on my
bad sector, but if the drive again detects a permantent error then it will
not reallocate the sector. First I still want to find which file contains
the sector; I haven't had time for this on weekdays.
When I ran the "long" S.M.A.R.T. self-test, the number of reallocated
sectors and number of reallocation events both increased from 1 to 2, but
the known bad sector remained bad. This is entirely because of the behavior
as designed. The self-test detected a temporary error in some other
unrelated sector, rescued the data in that unreported sector number, and
reallocated it. That was only a coincidence. The known bad sector was
detected yet again as permanently bad and was not reallocated.
In this mailing list there has been some discussion of whether file systems
should keep lists of known bad blocks and hide those bad blocks from
ordinary operations in ordinary usage. Of course historically this was
always necessary. As someone else mentioned, and I've done it too, when
formatting a disk drive, type in the list of known bad block numbers that
were printed on a piece of paper that came with the drive.
In modern times, some people think that this shouldn't be necessary because
the drive already does its best to reallocate bad blocks. WRONG. THE BAD
BLOCK LIST REMAINS AS NECESSARY AS IT ALWAYS WAS.
This design might change in the future, but it might not. My friends are
afraid that they might lose their jobs if they try to suggest such a change
in the high-level design of disk drive corporate politics. I only hope this
posting doesn't get them fired. (This is not a frivolous concern by the
way. The myth of lifetime employment is a less pervasive myth than it used
to be, and Toshiba is pretty much average in both world and Japanese
standards for corporate politics.)
Regarding finding which file contains the known bad sector, someone in this
mailing list said that the badblocks program could help, but the manual page
for the badblocks program doesn't give any clues as to how it would help.
I'm still doing find of all files in the partition and cp them to /dev/null.
Meanwhile, yes we do need to record those bad block lists and try to never
let them get allocated to user-visible files.
next prev parent reply other threads:[~2003-10-17 9:41 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-13 9:31 Why are bad disk sectors numbered strangely, and what happens to them? Norman Diamond
[not found] ` <200310131014.h9DAEwY3000241@81-2-122-30.bradfords.org.uk>
2003-10-13 10:24 ` Norman Diamond
2003-10-13 10:33 ` John Bradford
2003-10-13 11:30 ` Norman Diamond
2003-10-13 11:58 ` Maciej Zenczykowski
2003-10-15 10:22 ` Norman Diamond
2003-10-13 12:02 ` John Bradford
2003-10-15 10:23 ` Norman Diamond
2003-10-15 18:56 ` Pavel Machek
2003-10-14 6:54 ` Rogier Wolff
2003-10-13 14:24 ` Chuck Campbell
2003-10-13 14:54 ` Maciej Zenczykowski
2003-10-13 16:29 ` Roger Larsson
2003-10-14 6:49 ` Rogier Wolff
2003-10-14 7:05 ` Wes Janzen
2003-10-14 7:21 ` John Bradford
2003-10-14 7:40 ` Rogier Wolff
2003-10-14 8:11 ` John Bradford
2003-10-14 8:45 ` Hans Reiser
2003-10-14 9:46 ` Rogier Wolff
2003-10-14 9:57 ` Hans Reiser
2003-10-14 10:10 ` Rogier Wolff
2003-10-14 10:31 ` Hans Reiser
2003-10-14 10:19 ` John Bradford
[not found] ` <200310140800.h9E80BT9000815@81-2-122-30.bradfords.org.uk>
[not found] ` <20031014081110.GA14418@bitwizard.nl>
2003-10-14 8:55 ` Wes Janzen
2003-10-14 10:05 ` Rogier Wolff
2003-10-14 7:24 ` Rogier Wolff
2003-10-14 9:04 ` Hans Reiser
2003-10-15 10:23 ` Norman Diamond
2003-10-15 10:39 ` Hans Reiser
2003-10-17 9:40 ` Norman Diamond [this message]
2003-10-17 9:48 ` Blockbusting news, this is important (Re: Why are bad disk sectors numbered strangely, and what happens to them?) Hans Reiser
2003-10-17 11:11 ` Norman Diamond
2003-10-17 11:45 ` Hans Reiser
2003-10-17 11:51 ` John Bradford
2003-10-17 12:53 ` John Bradford
2003-10-17 13:03 ` Russell King
2003-10-17 13:26 ` John Bradford
2003-10-19 7:50 ` Andre Hedrick
2003-10-17 13:04 ` Russell King
2003-10-17 14:09 ` Norman Diamond
2003-10-17 9:58 ` Pavel Machek
2003-10-17 10:15 ` Hans Reiser
2003-10-17 10:24 ` Rogier Wolff
2003-10-17 10:49 ` John Bradford
2003-10-17 11:09 ` Rogier Wolff
2003-10-17 11:24 ` Krzysztof Halasa
2003-10-17 19:35 ` John Bradford
2003-10-17 23:28 ` Krzysztof Halasa
2003-10-18 7:42 ` Pavel Machek
2003-10-18 8:30 ` John Bradford
2003-10-21 20:26 ` bill davidsen
2003-10-18 8:27 ` John Bradford
2003-10-18 12:02 ` Krzysztof Halasa
2003-10-18 16:26 ` Nuno Silva
2003-10-18 20:16 ` Krzysztof Halasa
[not found] ` <m37k33igui.fsf@defiant. <m3u166vjn0.fsf@defiant.pm.waw.pl>
2003-10-21 20:39 ` bill davidsen
2003-10-17 10:37 ` ATA Defect management John Bradford
2003-10-21 20:44 ` bill davidsen
2003-10-17 12:08 ` Blockbusting news, this is important (Re: Why are bad disk sectors numbered strangely, and what happens to them?) Justin Cormack
2003-10-21 20:12 ` bill davidsen
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='11bf01c39492$bc5307c0$3eee4ca5@DIAMONDLX60' \
--to=ndiamond@wta.att.ne.jp \
--cc=R.E.Wolff@BitWizard.nl \
--cc=john@grabjohn.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nikita@namesys.com \
--cc=pavel@ucw.cz \
--cc=reiser@namesys.com \
--cc=superchkn@sbcglobal.net \
/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).