I have a drive that has had a few file corruptions. It seems to be due to getting very hot at some point in the past, the max reported temperature is 99C ! I've recovered as much data from it as I can with ntfsclone --rescue and mounted the image.

The reallocated sector count is zero but the current pending sector count is 233. I have read every sector on the drive (single partition) with the data recovery process but the drive has not changed the pending sector count. I find this strange, I thought that the drive should remap the pending sectors or decide they are fine.

I'm currently running a format with bad block checking on, the kernel is reporting i/o errors in the same blocks as before but still the drive is not reallocating sectors or changing the count. The output from the format is as follows:

    mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
61054976 inodes, 244190000 blocks
12209500 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
7453 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
        102400000, 214990848

Checking for bad blocks (read-only test):  11.06% done, 55:05 elapsed

I have to say, that this is a fair question. I can understand the nature of your expectations and believe them to be coherent - at some point I was under the same impression.

First, regarding temperature: I believe the data about 99C is wrong. That is already extreme overheating. Normal operating temperature, for a hdd, is somewhere about 20-45* C (55*C for higher capacity models). Anything over those limits and the drive's mechanics start to degrade much faster. Heat causes metal to expand - first to suffer would be the HSA (HeadStackAssembly). As the heads float over the platter (due to the air bearing) on extremely low altitude (but still not touching the surface of the platters) - you can see, how badly this could turn out, if something, this precise, starts to deform. That is why you should always provide adequate cooling. Also, there is a difference between the temperature inside the HDA (HardDiskAssembly, basically the temp. environment near the heads) - i.e. Seagate provides a SMART attribute just for this.

Now, to answer your question. The thing is, that only the most trivial cases are handled automatically. Usually, you won't get any sectors reallocated on a read operation. Only on a write. If there are difficulties with reading a sector (mismatching checksums), but the data was successfully recovered by ECC, then it just leaves the sector alone, without doing anything.

So, basically, if you overwrote the whole drive with zeroes - only then the drive's firmware would have remapped the troubling sectors to the reserved ones and would have decreased the value of SMART attribute #197. The reasoning here, is that the drive's ECC mechanism tries to do error correction and when it fails after a series of retries on the sector in question (perceived as timeout) - it simply flags the sector as UNC (uncorrectable, aka bad block). The problem here, is that it doesn't know how to deal with your data any further! And it shouldn't, as this is already your call. You will have to make a decision - postpone it and try to somehow recover the data in that sector at a later time or, instead, overwrite it and cause reallocation. Obviously, only one of these things can be done automatically and that is why it isn't.

What you are doing with mkfs, is only writing metadata, which will be placed at particular sectors. It will not populate the whole drive (so, it might never encounter any of the current bad sectors). However, a zero-fill would.

All in all, the drive is noticeably deteriorating. I would recommend a pass of dd (if=/dev/zero), if you still want to breathe some (short) life into it.

  • I did a pass of dd zeros and the machine eventually hung! after a reboot the pending sectors is zero but reallocated sectors have gone up to over 300, above the "max" value of the s.m.a.r.t. firmware. Looks like some distortion may have occurred as you predicted. It was due to using a cheap usb drive enclosure whose fan failed. :-/ – barrymac Feb 22 '12 at 23:56
  • 1
    Yes, that could happen. The head hits a spot on the platter and never returns a result again (point of failure, you need to cycle power in this case). Did you hear any funny (irregular) noises during that period? Any clunking or clicking? Also, there is one parameter that you can supply to dd, in order to make it deal with bad sectors more efficiently - conv=direct. This helps to recover more data on reads by the cost of execution time (r/w speed noticeably suffers). It might also, possibly, help on writes (prevent freezing). – XXL Feb 23 '12 at 10:03
  • Thanks for the extra info. I wasn't around but the drive hasn't been making any bad noises in general. In any case I found that some part of webmin was regularly doing a parted, and this conflicted with dd wiping the partition table! grr, removed this from the mix and it flew through the pass. I'm still holding a candle for this drive, as it's still got a smart pass status after a few long self tests and zero passes. Once it's done two passes with no increase in reallocated sectors I might use it for no critical stuff again – barrymac Feb 23 '12 at 11:39

You should probably zero disk i.e write it before read-testing. That would inhibit relocation and hopefully readback goes fine.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.