(PeteCresswell) said:
HD Sentinel was saying that one of my drives that I keep recorded
TV on was failing - as in 174 marginal sectors that could be
remapped at some future time.
That was yesterday and two days previous. During that time, I
saw it add marginal sectors several times.
Formatted a replacement drive and mirrored to it in expectation
of failure.
But today HD Sentinel says everything's just fine...
viz:
http://tinyurl.com/d2nzbfh
This thing didn't heal itself.... or did it?
I've rebooted a few times since yesterday. Am I seeing the
result of the XP re-mapping those sectors?
There are "Pending Sectors", and "Reallocated Sectors".
You'd check both SMART stats and reach your own conclusions.
If HDSentinel has documentation, see if the process and its
relationship to the HDSentinel graph, is mentioned.
I've never had a Pending Sector here, which is something
I don't understand. I have had Reallocated Sectors (which are
permanently spared out). Reallocated sectors increase with time.
Pending Sectors go "up and down". "Up", as they're queued for
processing. "Down", when a write attempt gives the drive a chance
to evaluate the sector.
A Pending Sector needs to be processed, and will be processed
on the next write attempt to the sector. Dodgy reads do not
cause immediate substitution. But a write to a known dodgy sector,
if that fails, a substitute sector is used, and the data structure
in the drive (substitution table) is updated.
On older IBM drives, I read documentation that explained that
about 1/8th of the RAM cache on the drive, was being used to hold
the substitution table. That's how the drive can quickly figure
out which sectors to transfer during DMA and the like. So if an entire
track is loaded into cache (the head can read continuously while
over the track), the substitution table tells the hardware
which sectors (normal or substitute) to send to the user. And that
information is presumably also written out to the platter, whenever
it is convenient (like, on a reallocation operation). The next time
the drive starts, it reloads the RAM using the copy of the substitution
table stored below track 0 (might be called "critical data" or the like).
Failures to properly load that info, causes the drive to stop responding,
a design feature I dislike. As a hardware guy, I like my hardware
to *always* respond, even if it's going to tell me a lot of bad news
So, check how the HDSentinel info, maps to those two SMART statistics.
Paul