[ale] what exactly does a long smart hdd test do?

[Michael H. Warfield]

I suddenly remember one very important critical point...

I'll edit heavily...

On Sun, 2012-05-13 at 14:33 -0400, Michael H. Warfield wrote:

> > Yon mention 3 things which SpinRite mainly does which I would agree
> > to.

> > 1) Deal with data fading.  This could also be called grown defects or
> > bit rot.

> The term "bit rot" is a nice euphemism which covers a number of things
> but is not a precise technical term.  But I know what you're saying.

> > I think we can certainly say that no magnetic surface is perfect, and
> > that some sectors or parts of sectors will be magnetically weak.

> No magnetic surface is perfect, agreed.  Modern controllers and
> manufacturing processes are designed to with with that as an assumption.

> I'm not quite sure I can buy into the "magnetically weak" aspect though.
> Such areas should be detectable by the analog sections of the controller
> electronics early in manufacturing and flawed out.  Once in operation,
> the the field strengths used by the heads, most especially the heads
> using in modern "vertical recording" where the magnetic poles of a bit
> domain are vertical and extend deeper into the recording media, rather
> than longitudinally along the surface of the track like older drives,
> should ensure a good strong penetration and the high mu media should
> hold that data for a very long time with no measurable fade.  There are
> things that a controller can detect, because it's processing the fields
> at an analog level, that can give indications of impending soft failures
> to which SpinRite would have no access at all.  These SHOULD show up in
> the SMART data, which is maintained by the firmware on the drive itself.

You are also missing one very VERY critical implication which I failed
to make apparent and I which totally forgot about...  SpinRite can not
truly do what it claims to do if you understand what I described about
the nature of modern drives and the quadrature servo patterns.  If this
bit-fade or bit-rot truly were a problem, the servo signals in between
the sectors would be just as susceptible and prone to failure.  SpinRite
can not rewrite those patterns.  In fact, nothing, outside of the
factory, can rewrite those half track quadrature patterns.  They are
recorded once at the time the drive is manufactured and can never be
overwritten or rerecorded again.  So, if the media were to be subject to
bit-rot there, SpinRite could do nothing about it.  If this were a
significant problem, drives would eventually become unstable.  The
probability is related to to the ratio of the relatively short servo
sync patterns to the length of a sector.  I forget the exact run length
of each but it looks (ascii graphically) something like this...

qqqq ssss ddddddddddddddddddddddddddddeeee ssss qqqq ssss

Where:

q = quadrature servo control patterns.
s = data sync patterns
d = sector data
e = ecc error code recovery data

The spaces would be "read / write" splice gaps.

Generally anything taking out those quadrature patterns or enough of the
leading data sync patterns is fatal.  I'm not totally sure all of the
data sync patterns are rewritten each time a sector is rewritten.  They
may be.  The splice gaps are there to allow for the heads to switch from
read to record with some allowance for timing and synchronization.

In the case of media flaws, the drive is capable of dead reconning over
several sectors if it missing the servo signals.  If it's more than
that, the entire track can be unusable.  So it's real critical that the
media be stable and not subject to magnetic fade.

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20120513/cd9a5bc7/attachment.bin