Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 7E73F2E008C for ; Tue, 18 Mar 2008 22:13:59 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 54138-05 for ; Tue, 18 Mar 2008 22:13:48 -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 4AB7A2E008D for ; Tue, 18 Mar 2008 22:13:55 -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 68C8A9E9; Wed, 19 Mar 2008 10:13:50 +0900 (WST) Received: from localhost (access [127.0.0.1]) by mail.postnewspapers.com.au (Postfix) with ESMTP id EC6E61E0436; Wed, 19 Mar 2008 10:13:50 +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 mcmr+dptLvdd; Wed, 19 Mar 2008 10:13:50 +0900 (WST) Received: from [10.0.0.125] (dhcp-125.localnet [10.0.0.125]) (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 1C37B1E0434; Wed, 19 Mar 2008 10:13:50 +0900 (WST) Message-ID: <47E068C8.5090500@postnewspapers.com.au> Date: Wed, 19 Mar 2008 10:13:44 +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> <47E045E9.8040809@postnewspapers.com.au> <1205888633.483.38.camel@hammy> In-Reply-To: <1205888633.483.38.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/391 X-Sequence-Number: 29345 Gregory Youngblood wrote: > In my way of thinking, and what I was referring to above, was using > those error conditions to identify drives to change before the reported > complete failures. Yes, that will mean changing drives before SMART > actually says there is a full failure, and you may have to fight to get > a drive replaced under warranty when you do so, but you are protecting > your data. > > I actually find it surprisingly easy to get a disk replaced based on a printed SMART report showing uncorrectable sectors or just very high reallocated sector counts etc. Almost suspiciously easy. I would not be at all surprised if the disk vendors are, at least for their 7200rpm SATA disks, recording a "black mark" against the serial number, doing a low level reformat and sending them back out as a new disk to another customer. Some of the "new" disks I've received have lifetimes and logs that suggest they might be such refurbs - much longer test logs than most new drives for example, as well as earlier serial numbers than others ordered at the same time. They're also much, much more likely to be DOA or develop defects early. > I agree with you completely that waiting for SMART to actually indicate > a true failure is pointless due to the thresholds set by mfrs. But using > SMART for early warning signs still has value IMO. > I could not agree more. smartmontools is right up there with tools like wireshark, mrt, and tcptraceroute in my most-vital toolbox, and it's mostly because of its ability to examine the vendor attributes and kick off scheduled self tests. I've saved a great deal of dead-disk-replacement hassle by ensuring that smartd is configured to run extended self tests on the disks in all the machines I operate at least fortnightly, and short tests at least weekly. Being able to plan ahead to swap a dying disk is very nice indeed. -- Craig Ringer