From: Hans Reiser <reiser@namesys.com>
To: Oleg Drokin <green@namesys.com>
Cc: Newsmail <newsmail@satimex.tvnet.hu>, reiserfs-list@namesys.com
Subject: Re: 'let the hdd remap the bad blocks'
Date: Mon, 19 Aug 2002 23:18:15 +0400 [thread overview]
Message-ID: <3D614477.8050500@namesys.com> (raw)
In-Reply-To: 20020819195906.A19984@namesys.com
Oleg Drokin wrote:
>Hello!
>
> Basically uyou'd better search for this on HDD vendors sites.
> What's going on is simply can be described this way:
> You write some block to HDD, if HDD decides the block is bad for some reason
> and remapping is allowed (usually by tiurning on SMART), block is written to
> different on-platter location and drive adds one more entry to its
> remaped-blocks list. Next time you read this block, drive consults its
> remapped blocks list and if block is remapped, reads it from new location
> with correct content.
> Described mechanism works for writing.
> Actually I've seen something that looks like remapping on read, though
> I have no meaningful explanation for that (except that they may have some
> extra redundant info stored when you write data to disk, so that if sector
> cannot be read, its content is restored with that redundant information and
> sector is then remapped.). And this process takes a lot of time.
>
>Bye,
> Oleg
>On Mon, Aug 19, 2002 at 03:58:30PM +0100, Newsmail wrote:
>
>
>>Hello Hans and Oleg,
>>maybe its an offtopic question, but Hans always talks about leaving the
>>hard disk to remap the bad blocks by itself. could you explain it in some
>>words, how all this works, what happens after, and since when it exists, or
>>do you have any special URL explaining this?
>>thx in advance,
>>greg
>>
>>
>>
>>
>>
>
>
>
>
Just taking a guess, many hard drives have difficult and time-consuming
procedures that they can go through to read a troublesome block. These
can take 20-30 seconds. Probably if they have to go through these
procedures, once they finally succeed the smart vendors remap the block.
Hans
next prev parent reply other threads:[~2002-08-19 19:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-19 14:58 'let the hdd remap the bad blocks' Newsmail
2002-08-19 15:59 ` Oleg Drokin
2002-08-19 16:23 ` Matthias Andree
2002-08-19 19:18 ` Hans Reiser [this message]
2002-08-20 9:27 ` Matthias Andree
2002-08-20 9:55 ` Hans Reiser
2002-08-20 10:13 ` Matthias Andree
2002-08-20 13:12 ` quota support ? Serge Kolodeznyh
2002-08-20 13:15 ` Oleg Drokin
2002-08-20 14:24 ` Serge Kolodeznyh
2002-08-20 14:39 ` Chris Mason
-- strict thread matches above, loose matches on Subject: below --
2002-08-27 22:36 'let the hdd remap the bad blocks' berthiaume_wayne
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=3D614477.8050500@namesys.com \
--to=reiser@namesys.com \
--cc=green@namesys.com \
--cc=newsmail@satimex.tvnet.hu \
--cc=reiserfs-list@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 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.