From: Lincoln Yeoh <lyeoh@pop.jaring.my>
To: Tom Lane <tgl@sss.pgh.pa.us>
To: Scott Ribe <scott_ribe@killerbytes.com>
Cc: Jim C. Nasby <jnasby@pervasive.com>
Cc: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: PostgreSQL General <pgsql-general@postgresql.org>
Subject: Re: [PERFORM] Arguments Pro/Contra Software Raid
Date: Sun, 14 May 2006 16:31:00 +0800
Message-ID: <5.2.1.1.1.20060514162127.027ea4f8@localhost> (raw)
In-Reply-To: <2711.1147449236@sss.pgh.pa.us>
References: <C08A0257.49C30%scott_ribe@killerbytes.com>
<C08A0257.49C30%scott_ribe@killerbytes.com>
At 11:53 AM 5/12/2006 -0400, Tom Lane wrote:
>Scott Ribe <scott_ribe@killerbytes.com> writes:
> >> My damn powerbook drive recently failed with very little warning
>
> > It seems to me that S.M.A.R.T. reporting is a crock of shit. I've had ATA
> > drives report everything OK while clearly in the final throes of death,
> just
> > minutes before total failure.
>
>FWIW, I replaced a powerbook's drive about two weeks ago myself, and its
>SMART reporting didn't show a darn thing wrong either. Fortunately, the
>drive started acting noticeably weird (long pauses seemingly trying to
>recalibrate itself) while still working well enough that I was able to
>get everything copied off it. I didn't wait for it to fail completely ;-)
Strange. With long pauses, usually you'd see stuff like "crc" errors in the
logs, and you'd get some info from the SMART monitoring stuff.
I guess a lot of it depends on the drive model and manufacturer.
SMART reporting is better than nothing, and it's actually not too bad. It's
just whether manufacturers implement it in useful ways or not.
I wouldn't trust the drive or manufacturer's judgement on when failure is
imminent - the drive usually gathers statistics etc and these are typically
readable with the SMART monitoring/reporting software, so you should check
those stats and decide for yourself when failure is imminent.
For example: I'd suggest regarding any non-cable related CRC errors, or
seek failures as "drive replacement time"- even if the drive or
Manufacturer thinks you need to have tons in a row for "failure imminent".
I recommend "blacklisting" drives which don't notice anything before it is
too late. e.g. even if it starts taking a long time to read a block, it
reports no differences in the SMART stats.
Link.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: lyeoh@pop.jaring.my, tgl@sss.pgh.pa.us, scott_ribe@killerbytes.com, jnasby@pervasive.com, pgman@candle.pha.pa.us, pgsql-general@postgresql.org
Subject: Re: [PERFORM] Arguments Pro/Contra Software Raid
In-Reply-To: <5.2.1.1.1.20060514162127.027ea4f8@localhost>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox