[Noisebridge-discuss] Linux disk stress test & burn-in

[Brian Morris]

Drives do have bad spots. I have found a few on used drives at least.
One that hung to freeze the computer which I returned for exchange
Some more that I located the bad spot using SMART and formatted around it
(leave the bad spot in Free Space) and used for years after that. One more
that lasted for maybe 6 months - it seemed borderline worn out before but
the customer wanted to keep it, I said as long as he backed everything up
...


You can do the extended off line test with SMART:
smartctl -t long /dev/sdx

takes hours.

Another way just as time consuming get a wipe program of your choice that
writes zeroes to the entire drive,

either way afterwards check the SMART error logs: smartctl -a /dev/sdx
(at the bottom)

Brian


On Thu, Jul 7, 2011 at 11:19 PM, Andy Isaacson <adi at hexapodia.org> wrote:

> On Thu, Jul 07, 2011 at 06:48:36PM -0700, Seth David Schoen wrote:
> > http://www.coker.com.au/bonnie++/
>
> I prefer fio(1).  http://linux.die.net/man/1/fio and
> http://git.kernel.dk/?p=fio.git;a=summary
>
> > It seems to me that trying to check for errors is very unlikely to
> > find anything, because hard drives have extensive internal soft
> > error correction.  The probability of an error that gets detected
> > by the drive and reported to SMART must be _much_ higher than the
> > probability of an error where bad data silently reaches the
> > application.
>
> Soft errors get reported in SMART as Hardware_ECC_Recovered and
> Reallocated_Sector_Ct and Raw_Read_Error_Rate (though how to interpret
> various vendors' RRER values is only documented in NDA materials AFAIK).
> You can also simply measure how long a given IO took to complete as a
> proxy for sector unreliability.
>
> I am pretty skeptical of the value of a burn-in cycle for disks; if you
> care so much about your data, just buy enterprise spindles (and pay the
> premium) or else use a software reliability layer above your cheap-ass
> SATA storage.  But, y'know, shrug.  To each his own data reliability
> model. :)
>
> -andy
> _______________________________________________
> Noisebridge-discuss mailing list
> Noisebridge-discuss at lists.noisebridge.net
> https://www.noisebridge.net/mailman/listinfo/noisebridge-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.noisebridge.net/pipermail/noisebridge-discuss/attachments/20110708/02db7b8c/attachment-0001.html>