X-Original-To: pgsql-general-postgresql.org@localhost.postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 220429FA3B3 for ; Sun, 14 May 2006 05:42:43 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 06780-01 for ; Sun, 14 May 2006 05:42:32 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from svr4.postgresql.org (svr4.postgresql.org [66.98.251.159]) by postgresql.org (Postfix) with ESMTP id C52869FA42B for ; Sun, 14 May 2006 05:42:32 -0300 (ADT) Received: from smtp5.jaring.my (smtp5.jaring.my [61.6.32.55]) by svr4.postgresql.org (Postfix) with ESMTP id 841E95B6419 for ; Sun, 14 May 2006 08:42:30 +0000 (GMT) Received: from nexus.localhost. ([218.208.193.198]) (authenticated bits=0) by smtp5.jaring.my (8.13.4/8.13.1) with ESMTP id k4E8bHHh073995; Sun, 14 May 2006 16:37:19 +0800 (MYT) (envelope-from lyeoh@pop.jaring.my) Message-Id: <5.2.1.1.1.20060514162127.027ea4f8@localhost> X-Sender: lyeoh@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Sun, 14 May 2006 16:31:00 +0800 To: Tom Lane , Scott Ribe From: Lincoln Yeoh Subject: Re: [PERFORM] Arguments Pro/Contra Software Raid Cc: "Jim C. Nasby" , Bruce Momjian , PostgreSQL General In-Reply-To: <2711.1147449236@sss.pgh.pa.us> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: JARING E-Mail Virus Scanner v2.0 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200605/659 X-Sequence-Number: 95451 At 11:53 AM 5/12/2006 -0400, Tom Lane wrote: >Scott Ribe 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.