On 27 October 2011 20:35, Mark Knecht <[email protected]> wrote:
> On Thu, Oct 27, 2011 at 11:41 AM, Jarry <[email protected]> wrote:
>> Hi, perhaps someone could explain this to me:
>>
>> I have bouth two the same hard-drives. The same model
>> (Hitachi HUA722050CLA330), the same firmware (JP20A3EA),
>> the same size (500GB). Well, not exactly. Both hdparm
>> and fdisk report different number of sectors (976771055
>> versus 976773168). Although not a big difference, yet
>> I expected them to be exactly the same (want to use
>> them for raid1).
>>
>> So how is it possible they do not have the same number
>> of sectors? I have bought them from one supplier, even
>> their serial numbers are very close (only the last 2
>> characters out of 24 are different)...
>>
>> Jarry
>
> Maybe one has some stuff mapped out due to bad blocks found during
> manufacturing or something like that? Not sure what it will tell you
> but have you run smartctl on the drives and looked around at what they
> tell you to find any differences?
>
> - Mark

During normal operation, if a bad block is detected, that sector is
marked as 'bad', and a one of the free sectors (which are additional
to your totals) is allocated to replace it. This is called
Re-Allocating Sectors, and according to the Google paper[1], which
seems to be the only authoritative (non-marketing, non
industry-funded) source on hard-drive failure, re-allocated sectors
are indicative of impending drive failure. You can check your
Re-Allocated sector count using smartmontools (but I recommend that
you try gsmartcontrol in sunrise, which makes life easier).

This is made more complicated by the fact that if bad sectors (below a
manufacturing threshold) are detected in factory testing, they will
re-allocate them, and reset the SMART counter to Zero (the drive _is_
brand new after all!). Thus, you can buy two of the exact same model
of drive, and yet have different numbers of available sectors.

It is also possible that something entirely different is at play.

[1] labs.google.com/papers/disk_failures.pdf

Reply via email to