From: Gregory Youngblood <greg@tcscs.com>
To: Craig Ringer <craig@postnewspapers.com.au>
Cc: david@lang.hm, Andrej Ricnik-Bay <andrej.groups@gmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: What is the best way to storage music files in Postgresql
Date: Tue, 18 Mar 2008 18:03:53 -0700
Message-ID: <1205888633.483.38.camel@hammy> (raw)
In-Reply-To: <47E045E9.8040809@postnewspapers.com.au>
References: <8fb205ea0803152311n2c950758g253f4cefd20cff7d@mail.gmail.com>
<47DCBD63.9050109@postnewspapers.com.au>
<4544e0330803171101g680ffa5bj8ac32908a9f3dfb5@mail.gmail.com>
<8fb205ea0803171139h63b55fdrf62776851583a74d@mail.gmail.com>
<4544e0330803172026h3eae59a1u8914bda1a5a95bb5@mail.gmail.com>
<b35603930803180213v6a3c2e64i8a65eca5472c0b49@mail.gmail.com>
<47DF9278.70605@postnewspapers.com.au>
<b35603930803181044y666f0e7r66b6d2606812a354@mail.gmail.com>
<alpine.DEB.1.00.0803181104010.21250@asgard.lang.hm>
<1205866336.483.5.camel@hammy>
<47E045E9.8040809@postnewspapers.com.au>
On Wed, 2008-03-19 at 07:44 +0900, Craig Ringer wrote:
> 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.
-->8 snip 8<--
In that Google report, one of their conclusions was that after the first
scan error drives were 39 times more likely to fail within the next 60
days. And, first errors in reallocations, etc. also correlated to higher
failure probabilities.
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 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.
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: greg@tcscs.com, craig@postnewspapers.com.au, andrej.groups@gmail.com
Subject: Re: What is the best way to storage music files in Postgresql
In-Reply-To: <1205888633.483.38.camel@hammy>
* 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