lkml.org 
[lkml]   [2003]   [Oct]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Blockbusting news, results are in
Date
Eric Mudama replied to me:

> > Does anyone need more?
>
> Why don't you ask your friends at Toshiba whether that model supports
> automatic reallocation, and if it does, how to enable it?

1. I didn't have to ask whether it does, because the S.M.A.R.T. logs
already showed that it had done so. The probelm is that it didn't do so to
the block that was involved in this issue.

2. I did ask a different question, why that particular block wasn't getting
reallocated, and my friends answered, and this answer was already reported
in this thread a few days ago.

3. If there were a way to enable reallocation in case of permanent errors,
I think my friends would have said. But they sure didn't say there were any
user-settable options, they only said some approximations of how it was
designed. It does reallocations after temporary read errors but not after
permanent read errors (where permanent means 255 failures in auto-retry).
They think it does reallocations after temporary write errors, they weren't
sure if it does reallocations after permanent write errors, now we know that
it doesn't do reallocations after permanent write errors, and this is how it
is designed, with no hint of options to toggle.

> > We do not know if Toshiba is the only maker whose firmware
> > refuses to reallocate bad blocks when permanent errors are
> > detected, because the makers aren't saying.
>
> What would you like "us disk makers" to say?

How to force reallocations even when data are lost, so that the block number
can still be accessed even though the data will be random or zeroes until it
gets written again. How to force reallocations even when data are lost, to
prevent a different problem (i.e. if the block is not reallocated and then a
subsequent write appears to succeed, I don't really think that spot on the
platter has really reliably recovered even if you think so, I think the new
data might still get lost again in a few milliseconds or minutes).

> If every other part of your computer is warrantied for 1 year, why should
> disk drives alone in the cheapest OEM systems carry 3 year warranties?

Why does RAM carry 6 year warranties? (Maybe some don't but this is
common.)

> BTW, you're welcome to buy "premium" drives with 3-year or 5-year
> warranties. (3 on most vendor's high end ATA products, and 5 years on
> most SCSI products)

I haven't seen that, even on a SCSI product.

Meanwhile, regarding ATA and warranties, here's a question for you. I
bought a Maxtor 80GB desktop hard drive at a time when it was a high end
product. The drive came with two sets of instructions, one in Japanese and
one in English. Which set of instructions do you think most customers read
here in Japan? And then which set of instructions do you think was more
likely to have correct jumpering instructions? I couldn't quite be sure
which set of jumpering instructions to believe, because even though Maxtor's
parent might be in the US (I'm not sure actually), I did buy this thing in
the Japanese market with Japanese packaging and one of the two sets of
instructions in Japanese. So I sent e-mail to Maxtor to ask which
instructions were correct, but Maxtor didn't answer. I phoned Maxtor, and
it turned out that the phone number was answered in Singapore, and the
person didn't answer my question but gave a different e-mail address for me
to send my question to. So I sent e-mail to Maxtor's different e-mail
address to ask again which instructions were correct and explain everything
that had happened so far. Maxtor still never answered. Would you like to
know why my level of trust in Maxtor drives is as low as it has been in IBM
drives since a previous experience and has been in Toshiba drives for the
past week? This doesn't exactly reflect drive reliability unless I guess
wrong which set of jumpering instructions to obey. But still, suppose I
guessed wrong, then would Maxtor provide a warranty?

> In most cases these premium warranties will only cost you $5-$10.

I've still never seen them on parts that way, not for 550 yen or 1,100 yen
or any other amount. I've occasionally seen it on entire computers, for
example Dell, or a store warranty at Bic Camera, for around 5% of the price
of the computer.

> > If their disk drives start to develop bad blocks after two
> > years, then customers don't discover how bad Toshiba's firmware
> > is until two years have passed, and now they can't even make
> > claims to get firmware fixed.
>
> What do you want "fixed" in the firmware?

Reallocate bad blocks when bad blocks are detected, even in situations when
the badness is detected as permanent. This answer hasn't been clear yet
from this thread?????
> I still don't understand why your Toshiba engineer friends couldn't help
> you beyond listening to the drive bounce off the crash stop.

They're not sure yet if they can. Officially of course they can't, because
of the warranty rules that have already been discussed.

> (BTW, if the drive is clunking because it can't acquire at a certain
> location, odds are that more than just the user data at that sector is a
> problem.

It didn't sound like clunking. It sounded like repeated seeks. It didn't
sound like 255 repeated seeks, so I'm guessing it probably does something
like try 15 retries without seeking, then seek again and try another 15
times, etc.

Meanwhile, the end result still holds. In at least some cases, known
defective firmware is refusing to do reallocations when reallocations are
possible. Other makers' firmware is less known. We still need to keep
lists of bad blocks known by the OS and filesystems and drivers, and we
still need to keep those blocks away from ordinary file operations. These
lists remain as necessary as they ever were. Unless we get some guarantees
of good behavior by drives, if we don't make lists of bad blocks then we
will have to say that Linux and disk drives shouldn't be used together in
any computer.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:58    [from the cache]
©2003-2011 Jasper Spaans