2

I have a retired HDD with a high "Reallocated Sector Count" (maybe greater a thousand, if I remember correctly). Today, I performed a ATA Secure Erase via hdparm, and after that, this count becomes zero. It remains to be zero after finishing smartctl -t long. The "Raw Read Error Rate", "Seek Error Rate", "Reallocated Event Count", "Current Pending Sector", "Offline Uncorrectable" are also zero. I have some questions for which I don't find definitive answers after searching.

  1. Why do "Reallocated Sector Count" and relevant counts become zero after Secure Erase? Does this mean that there are no real badblock and it is due to incorrect reading of SMART?

  2. If these counts underestimate the real number of badblocks, how can I read the correct number of badblocks after a Secure Erase?

Improve this question
6
  • 1
    Maybe test it using software. Do keep in mind that SMART is a mess and every drive maker basically does what it wants.
    – Daniel B
    Commented Aug 17, 2022 at 17:45
  • So some bad sectors are "soft" (eg can be corrected with a full format) and others are "Hard". I recommend formatting the disk for a filesystem and perform a full filesystem scan that checks your freespace. that should cause the "hard" bad sectors to be located and remapped again.
    – Frank Thomas
    Commented Aug 17, 2022 at 18:09
  • If you're on Windows, format the disk with a slow (not quick) format. This will write every sector and find bad sectors. For a large disk, this will take time.
    – harrymc
    Commented Aug 17, 2022 at 18:24
  • @FrankThomas Do you suggest that neither ATA Secure Erase (which, if I understand correctly, fill-zero the whole device by the firmware, something at lower level than dd if=/dev/zero), nor smartctl -t long would detect and remap bad sectors?
    – Yai0Phah
    Commented Aug 17, 2022 at 21:46
  • @FrankThomas If I understand correctly, fsck invokes badblocks, which is simply performing read/write tests sector by sector, and mark all sectors with I/O errors. However, I heard that "modern" HDD's hide bad sectors in that, during an access to a bad sector, from the outside it looks like reading or writing the same sector but internally remapped to another, so the outsider no longer "knows" that this is a bad sector. I am trying to understand whether these SMART counts record the number of these internally remapped sectors, say.
    – Yai0Phah
    Commented Aug 17, 2022 at 22:09

2 Answers 2

Reset to default
1

As opposed to Pending Sectors, which are going to be re-assessed on their next generic write operation, Reallocated Sectors are excluded from normal read/write operations, so they usually aren't re-assessed anymore.

However ATA Secure Erase is intended to erase everything, including rewriting over remapped sectors (just in case parts of your data are still locked into them). Re-assessing them on this occasion.

It looks like your Reallocated Sectors weren't so defective, at the end, but a double check would be welcome.

Please be aware: This doesn't necessarily reset Reallocated Sectors Count. As an example, after full ATA Secure Erase, on a ST4000DM005, the count decreased a little bit, but didn't go back to zero. On a ST9500325AS, I found out they weren't even re-assessed.

Difficult to say what made them defective previously, if they finally aren't anymore:

  • was it external conditions (mounting, vibrations, unstable voltage...)
  • was it internal conditions (sticky grain of dust finally gone from the plate, writing head becoming too weak...).

It's still possible with shred or dd to fulfill your drive of random data, and to read it back (with dd iflag=direct) to ensure it's still doing fine while reading something else than zeroes, then checking SMART values again.

Reminder:
Be careful with drives that previously shown signs of failure, but with all drives anyway. Valuable data can be vulnerable to a lot of accidental and malicious things without a proper backup policy that allows retrieving and going back.

Improve this answer
6
  • Bad sectors may still be there, what if secure erase simply moves unrepairable sectors from G List to P List?
    – Joep van Steen
    Commented Jul 8 at 13:44
  • Reallocated sectors have been re-assessed, a drive doesn't just reallocate sectors just like that. For example a 'soft' error results in pending sector, but once the sector is being written to it is examined and will not be reallocated if the sector is found to be OK.
    – Joep van Steen
    Commented Jul 8 at 13:49
  • Hi Joep, on a Seagate ST4000DM005, that still has 1696 Reallocated Sectors according to SMART "reallocated sector count" after an ATA Secure Erase, using UART 1.8V TTL port and F3 commands, the G-List still returns a ton of entries (probably listing these reallocated sectors). So it looks like ATA Secure Erase didn't move them (or at least, not all of them) to the P-List (count was more than 1800 before ATA Secure Erase). But because of "Diagnostic Port Locked" I can't get much more information.
    – Julien Robin
    Commented Jul 8 at 15:59
  • Hey @julien , Could different brands handle this differently perhaps?
    – Joep van Steen
    Commented Jul 8 at 18:23
  • I have done some more research and I can not find much support for my answer, so deleted that. With regards to 'reallocated sector count', secure erase addresses those too but it does not clear g-list as far as I can find. Reallocated sector count only partially resetting seems indeed to suggest that it can fix some sectors but not all? Weird and vague. Frustrating that this type of stuff is so hard to get good info about.
    – Joep van Steen
    Commented Jul 8 at 21:31
0

Why do "Reallocated Sector Count" and relevant counts become zero after Secure Erase? Does this mean that there are no real badblock and it is due to incorrect reading of SMART?

According to several drive manufacturer documents, Secure Erase targets reallocated sectors, example:

" Enhanced Erase mode, all previously written user data shall be overwritten, including sectors that are no longer in use due to reallocation.” - source.

SMART values for reallocated sectors reflects the grown defects list (G-List). So sectors that are found to be 'bad' after the hard drive left the factory are moved to the G-List and these are published via SMART (reallocated sectors count).

Indeed a sector may turn out to be good after re-examining it during a secure erase. For example due to vibration a drive may be unable to locate a sector which is normally a serious error and thus reallocation worthy, or read it after significant error recovery and such a sector may be reallocated on-the-fly. If the sector is re-tested during a secure erase and reads without issue it can be put back in service.

It might possible drives themselves move G-List sectors to the P-List. I don't have direct evidence supporting this however I do know certain drive brand and models support the so called "format unit" command. This is a vendor specific command (so not part of some standardized spec. like ATA) that erases user data and 'merges' the G en P lists:

"The Format Unit command initializes all user data sectors after merging reassigned sector location into the defect information of the device and clearing the reassign information. Both new reassign information and new defect information are available right after command completion of this command. Previous information of reassign and defect are erased from the device by executing this command."

What I therefore think that could be happening in certain models during a Secure Erase is sectors that can not be 'repaired' are moved from the G-List to the P-List and SMART 'reallocated sectors count' reflects the now empty G-List. IOW, a drive may do a format unit procedure when Secure Erase command is received.

I again must stress I am speculating here.

If these counts underestimate the real number of badblocks, how can I read the correct number of badblocks after a Secure Erase?

You can normally not read the 'correct' number of bad blocks, the hard drive manufacturer decides what the drive publishes. What SMART shows you are grown defects, not bad blocks already detected during the manufacturing. However tools do exist, exploiting vendor specific commands, that have access to the P-List.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .