SSD has "Damaged Sectors"

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
The diagnostic "HD Tune" reports 2 damaged sectors on a SSD "Intel
SSDSC2BW120A401" and that "the number of damaged sectors which have
been replaced = 2".
Can I keep using this?

Re: SSD has "Damaged Sectors"

Peter Jason wrote:

Quoted text here. Click to load it
are you using it at the moment?

Re: SSD has "Damaged Sectors"

Peter Jason wrote:
Quoted text here. Click to load it

You should be using a Toolbox from your SSD company.

    Intel SSD Toolbox - v3.3.0.exe

HDTune may be alerting you to sectors which have already
been replaced. This would show as "Reallocated Sector Count".

Intel_SSD_Toolbox_3_3_0_User_Guide.pdf page 14 shows
that parameter is #05 which is "Re-allocated Sector Count".
Check to see if toolbox reports a value of 2 for that entry (#05).


If, on the other hand, you see a red block here, this
means a sector is currently unreadable. This situation
should be handled with more care, if it occurs. Repairing
this with CHKDSK, could result in a non-booting C: .

" CHKDSK C: /r " would scan and find the bad sector, and
mark the whole cluster as bad (add to the metadata file
$BADCLUS). But it would also likely put the damaged file
in lost&found if it did that, and if the file involved
was the system kernel file, the disk might not boot.

So I hope to hear from you, that there is no red block in
a scan, this is just a regular "reallocated" sector.
Sectors are reallocated on write, so a pending sector
might get reallocated the next time that sector
is written.

The nice thing about spares on an SSD, is they have no
"locality". When a hard drive spares out a bad sector,
it uses a sector which is "near by" the damaged one.
If the disk has a bad spot, the hard drive can
"run out of spares" next to the damage. Then, those
red blocks start showing up, as the damage can no longer
be repaired.

On an SSD on the other hand, *every* LBA on the disk
is handled by indirection. Sector 0 might be at 1234,
and sector 1 might be at location 5678 in the Flash chip.
The data in the flash chip is scrambled, and a lookup
table is what makes sense out of the data. So when a
sector is spared out, and a good sector used in its
place, it's just a repair to the lookup table. This should
allow a "bad spot" in an SSD, to be repaired with no
trouble at all. The drive can use a spare from anywhere
within the flash matrix. There are no locality issues,
merely the size of the remaining supply of spares.

In a Toolkit, you look at parameters such as "wear life",
or whatever passes for percentage of spares, to decide
whether the SSD is in any real trouble.

Now, looking at that HDTune Pro output above, if I was
given an LBA (logical block address) value like
181291904, I would use the output of Microsoft "nfi.exe"
from the old Win2K toolkit, to understand what file it
might be. The block could be in the middle of an
unused cluster (nobody gets hurt).

This is a file description from NFI. If 181291904
was anywhere in the range 390528-390543, then I would
know that "vgasys.fon" file was damaged. The file format
is not that convenient for discovering which file that
is, but the information is still present if you want
it bad enough. I have some NFI files with 25MB of text,
so you really need an automated way to figure out
which file is involved. I think I may have written
a script to do that at some point.

File 20071
     $FILE_NAME (resident)
     $FILE_NAME (resident)
     $DATA (nonresident)
         logical sectors 390528-390543 (0x5f580-0x5f58f)  <---


If you have a red block in your HDTune scan, that
spells potential trouble as well, for doing backups.
There are many backup tools which will throw a
wobbly if they run into a red block.

If no file is stored in the red block, then tools
that do intelligent copy, they won't go near the red

If you resolve the red block issue this way...

    CHKDSK C: /r

any file containing a red block might get removed,
but then again, the entire cluster is marked as
out-of-bounds, by being added to $BADCLUS for the
NTFS file system. And this is good, in the sense
that future backup attempts will now succeed. Because
again, using intelligent copy, no backup software
will need to visit the red block. It is "segregated".
No attempt can be made to use the red block,
unless the NTFS partition is reformatted and
the recordings in $BADCLUS are removed.

Error recovery works at two levels. Automated handling
at the disk (SSD) level. This is why I suspect the message
you're seeing is just the Reallocated Sector Count
field, and not something super-critical. Monitoring
overall drive health, the rate of bad sector growth,
may be sufficient for that.

If a storage device gets bad enough to show a red
block (it shouldn't), NTFS has CHKDSK and $BADCLUS
to deal with the bad guys. (The red block will remain
in HDTune, but NTFS ensures it won't cause a problem.)
But at this point, you should be seriously considering
changing out drives, as the automated recovery on the
drive itself should be hiding all the red blocks.


Using the Toolbox for your SSD is essential, for
keeping ahead of any health issues it might have.
SSDs will brick themselves at end-of-life, leaving
you with no data at all. This is why, even one backup
of the thing, is better than nothing at all. And if
the drive only has 10% life left, then you should
be backing it up every day. Because you know failure
is right around the corner. The Toolbox is likely
to have a "coloring scheme" to alert you to this
fact. Or maybe something starts flashing in the


Re: SSD has "Damaged Sectors"

Quoted text here. Click to load it

Thanks.  The Intel diagnostic gave it an all clear.

Re: SSD has "Damaged Sectors"

Peter Jason wrote:

Quoted text here. Click to load it

Just for fun, did you try HDTune bad block scan anyway ?

Even if it takes half an hour, it would be reassuring to
see "all green". As that's what I'm expecting here. There
really should not be any red blocks.


Re: SSD has "Damaged Sectors"

Quoted text here. Click to load it

I tried this and all were green.  However the "Speed Map" pattern gave
some blocks with a yellow tinge, indicating slower read/write on

Site Timeline