Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id D06DA2E0082 for ; Tue, 18 Mar 2008 19:45:14 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 57087-04 for ; Tue, 18 Mar 2008 19:45:12 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from www.postnewspapers.com.au (www.postnewspapers.com.au [202.61.230.242]) by postgresql.org (Postfix) with ESMTP id 985E22E0038 for ; Tue, 18 Mar 2008 19:45:11 -0300 (ADT) Received: from mail.postnewspapers.com.au (202-89-185-120.static.dsl.amnet.net.au [202.89.185.120]) by www.postnewspapers.com.au (Postfix) with ESMTP id 60B8EC3FB; Wed, 19 Mar 2008 07:45:05 +0900 (WST) Received: from localhost (access [127.0.0.1]) by mail.postnewspapers.com.au (Postfix) with ESMTP id DAEC91E0435; Wed, 19 Mar 2008 07:45:05 +0900 (WST) X-Virus-Scanned: Debian amavisd-new at postnewspapers.com.au Received: from mail.postnewspapers.com.au ([127.0.0.1]) by localhost (access.postnewspapers.com.au [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ePwGWmFnBFJj; Wed, 19 Mar 2008 07:45:03 +0900 (WST) Received: from [203.161.97.213] (203.161.97.213.static.amnet.net.au [203.161.97.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Craig Ringer", Issuer "POST Certificate Authority" (verified OK)) by mail.postnewspapers.com.au (Postfix) with ESMTP id 1D5611E0434; Wed, 19 Mar 2008 07:45:03 +0900 (WST) Message-ID: <47E045E9.8040809@postnewspapers.com.au> Date: Wed, 19 Mar 2008 07:44:57 +0900 From: Craig Ringer User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Gregory Youngblood Cc: david@lang.hm, Andrej Ricnik-Bay , pgsql-performance@postgresql.org Subject: Re: What is the best way to storage music files in Postgresql References: <8fb205ea0803152311n2c950758g253f4cefd20cff7d@mail.gmail.com> <47DCBD63.9050109@postnewspapers.com.au> <4544e0330803171101g680ffa5bj8ac32908a9f3dfb5@mail.gmail.com> <8fb205ea0803171139h63b55fdrf62776851583a74d@mail.gmail.com> <4544e0330803172026h3eae59a1u8914bda1a5a95bb5@mail.gmail.com> <47DF9278.70605@postnewspapers.com.au> <1205866336.483.5.camel@hammy> In-Reply-To: <1205866336.483.5.camel@hammy> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200803/384 X-Sequence-Number: 29338 Gregory Youngblood wrote: > Also, a very informative read: > http://research.google.com/archive/disk_failures.pdf > In short, best thing to do is watch SMART and be prepared to try and > swap a drive out before it fails completely. :) > I currently have four brand new 1TB disks (7200RPM SATA - they're for our backup server). Two of them make horrible clicking noises - they're rapidly parking and unparking or doing constant seeks. One of those two also spins up very loudly, and on spin down rattles and buzzes. Their internal SMART "health check" reports the problem two to be just fine, and both pass a short SMART self test (smartctl -d ata -t short). Both have absurdly huge seek_error_rate values, but the SMART thresholds see nothing wrong with this. The noisy spin down one is so defective that I can't even write data to it successfully, and the other problem disk has regular I/O errors and fails an extended SMART self test (the short test fails). I see this sort of thing regularly. Vendors are obviously setting the SMART health thresholds so that there's absolutely no risk of reporting an issue with a working drive, and in the process making it basically useless for detecting failing or faulty drives. I rely on manual examination of the vendor attributes like the seek error rate, ECC recovered sectors, offline uncorrectable sectors (usually a REALLY bad sign if this grows), etc combined with regular extended SMART tests (which do a surface scan). Just using SMART - say, the basic health check - really isn't enough. -- Craig Ringer