> On Sun, 14 Oct 2001, Kip Macy wrote:
>
> > S.M.A.R.T. and SMART are not the same thing. A quick google search got me
> > to this page:
> >
> > <http://www.belarc.com/Images/blank.gif>
> > [About S.M.A.R.T.]
> > S.M.A.R.T. (Self-Monitoring Analysis and Reporting Technology) is a
> > diagnostic method originally developed by I.B.M. for their mainframe
> > drives to give advanced warning of drive failures. Large mainframe data
> > centers wanted to know in advance if a hard disk drive was going to fail,
> > because this gave them the opportunity to take steps to protect their
> > data. Later Compaq announced a diagnostic which operated with a number of
> > different disk drive manufacturers. These products were submitted to the
> > ATA/IDE standards committees and the resulting standard was named
> > S.M.A.R.T. Today all major hard disk drive manufacturers support
> > S.M.A.R.T., including IBM, Western Digital, Quantum, Seagate, and Fujitsu.
> > etc.
On Sun, Oct 14, 2001 at 08:08:35PM -0700, Kip Macy wrote:
> On second thought they most likely are the same thing. And, just in case
> it is not obvious, it is telling you to back up your data because it
> thinks the drive is about to fail.
>
> -Kip
Yes, some BIOSes have "S.M.A.R.T." and some "SMART".
Thanks for the history lesson and research...
Cyrus, replace that drive, or at least test it with badblocks. One thing
that I've noticed about badblocks is that there are times when part of a
drive is about to go bad, but doesn't give an error message. It just takes
longer, and uses several reads but finally completes successfully. The
only time I've noticed this was on
a drive where badblocks *did* find an error, but there were parts that took
much too long to read, and probably should've been marked faulty. (This was
with badblocks in e2fsprogs 1.18). Though, taking a long time to read could
be caused by other users on a multi-user system, but if there is a way to
detect if a drive is retrying to read, that would be a good way to check...
BTW Cyrus, your mail bounced, so if you take the time to read the archive,
you'll know...
----- The following addresses had permanent fatal errors -----
<cyrus@linuxmail.org>
(reason: 521 sorry, user inactive)
Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/