Bad Blocks... Should I RMA?

[Roland Smith]

On Mon, Nov 16, 2009 at 09:43:31PM +0000, Bruce Cran wrote:
> On Mon, 16 Nov 2009 19:23:58 +0100
> Roland Smith <rsmith at xs4all.nl> wrote:
> 
> > Install the smartmontools port, and check the drive with 
> > 'smartctl -a /dev/ad4'. If you see a non-zero Reallocated_Sector_Ct,
> > RMA it immediately, as it is about to fail. If see other errors
> > reported, RMA it.
> > 
> > (S)ATA disk have spare sectors available. If a sector fails, it is
> > replaced by one of the spares by the firmware. If you see a non-zero
> > Reallocated_Sector_Ct, it means that the drive has run out of spares.
> > This is bad news.
> 
> Surely it's the other way around - if you see a value of zero in the
> "value" column the drive has run out of spare sectors and it's time to
> RMA the drive?

I was talking about the _RAW_VALUE column. There seems to be some differences
in interpretation between vendors as to what the VALUE column means. Most of
the advice I've seen over the years says to look at the RAW_VALUE.

See http://en.wikipedia.org/wiki/S.M.A.R.T. as well.

> From what I've seen the 'raw' column appears to count
> the number of sectors the drive has remapped using the spares buffer.
> If it gets into the hundreds it's probably time to think about RMA'ing
> the drive

Yes, the raw value is the number of sectors allocated from the spares. I
originally thought it was the number of reallocations _beyond_ the
spares. That's a misunderstanding on my part.

Nevertheless this attribute (along with several) is marked on the Wikipedia
page for smart as a "Potential indicator of imminent electromechanical
failure". You can find the same attributes marked as critical when perusing
mailing list archives.

For me, my data is worth much more than the harddisk it is on. Some of it is
literally irreplacable. So my policy is to go look for a replacement harddisk
as soon as the RAW_VALUEs of any of these critical indicators start going up
from zero. And store any data at least on two harddisks, whether in a mirror
or in a cron+rsync setup.

Roland
-- 
R.F.Smith                                   http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20091116/aada5b97/attachment.pgp