Re: [Hampshire] Laptop Hardrive

Top Page

Reply to this message
Author: James Courtier-Dutton
Date:  
To: Hampshire LUG Discussion List
Subject: Re: [Hampshire] Laptop Hardrive
On 19 May 2010 12:22, Hugo Mills <hugo@???> wrote:
> On Wed, May 19, 2010 at 11:58:14AM +0100, Vic wrote:
>>
>> > Yes, if data is actually unrecoverable (as happened in my notebook's
>> > hard disc: 3 bad sectors at the time of replacement, lost a video) the
>> > drive will kick up a fuss-load of ATA errors, which will be reported all
>> > over dmesg.
>>
>> That's for broken sectors, not sector reallocation; if the data is
>> actually gone from the drive, there's nothing you can do about it.
>
>   The main route to discovering you've got a failed drive or part of
> drive is when you can't read the data that was originally put on
> it. This will come to light either when a checksum is computed and
> fails comparison, or when part of the hardware is operating outside
> the parameters that are expected of it. When that happens, you have
> already lost data.
>
>> The purpose of SMART is to notice impending failures before they get to
>> such a critical level,
>
>   It's not very good at it, though. The famous Google paper on disk
> failures quotes a model (under "related work", page 11) with only a
> 30% success rate based on SMART information. They also state (section
> 3.5.6, page 10) that 56% of failed drives show no failure indicators
> at all in the four main SMART fields, and 36% of the failed drives
> show no failure indicators in SMART _at all_.
>
>   Detecting failures and fixing them before they're going to occur is
> a nice fairy-tale, but in the real world, it's just not going to
> happen unless you're very lucky.
>
>> and move data away from the failing areas into
>> spare sectors. It's not perfect but, absent any significant external
>> events (like dropped disks), it's pretty good.
>
>   SMART is simply a reporting process (plus a self-test feature) --
> the drive still does sector reallocations even if SMART itself is
> turned off.
>
>   Now, regarding the sector reallocation process: My understanding is
> that the drive will reallocate a sector if it has trouble reading
> it. So, if the drive electronics generates an internal error and
> causes a re-read, it _may_ attempt to move the sector, writing the
> data that it read from the troublesome sector to a spare.
>
>   Now, I doubt that it will do this on the first problematic read,
> but after enough sequential retries where it's had a problem, it will
> trigger this behaviour. I don't know how many internal retries are
> needed. I would guess at 3-4. If there's damage to the sector
> (physical or checksum), then the data that's read and rewritten may
> not be the data that was originally put on the disk. In this instance,
> it may not be 512 bytes of zeroes, but it's not guaranteed to be
> identical.
>
>   Hugo.
>


My understanding of reallocation is the same as Hugo's. Maybe I just
explaining it badly.
My understanding of reallocation is not the same as Vic's.

I would add to Hugo's in that I believe that an entry will appear in
the syslog when the reallocation happens.