From: Tomas Vondra <tv@fuzzy.cz>
To: gnuoytr@rcn.com
Cc: pgsql-performance@postgresql.org
Subject: Re: Reports from SSD purgatory
Date: Wed, 24 Aug 2011 22:10:28 +0200
Message-ID: <7fb128a72b9945f6b905d563c67ebffc.squirrel@sq.gransy.com> (raw)
In-Reply-To: <201108241942.061270@ms14.lnh.mail.rcn.net>
References: <4E49B0A0.2060705@2ndQuadrant.com>
<201108241848.061232@ms14.lnh.mail.rcn.net>
<d32d411b09d8e7c614772de567a94229.squirrel@sq.gransy.com>
<201108241942.061270@ms14.lnh.mail.rcn.net>
On 24 Srpen 2011, 21:42, gnuoytr@rcn.com wrote:
>
>
> ---- Original message ----
>>Date: Wed, 24 Aug 2011 21:32:16 +0200
>>From: pgsql-performance-owner@postgresql.org (on behalf of "Tomas Vondra"
>> <tv@fuzzy.cz>)
>>Subject: Re: [PERFORM] Reports from SSD purgatory
>>To: gnuoytr@rcn.com
>>Cc: pgsql-performance@postgresql.org
>>
>>On 24 Srpen 2011, 20:48, gnuoytr@rcn.com wrote:
>>
>>> It's worth knowing exactly what that means. Turns out that NAND
>>> quality
>>> is price specific. There's gooduns and baduns. Is this a failure in
>>> the
>>> controller(s) or the NAND?
>>
>>Why is that important? It's simply a failure of electronics and it has
>>nothing to do with the wear limits. It simply fails without prior warning
>>from the SMART.
>
> It matters because if it's the controller, there's nothing one can do
> about it (the vendor). If it's the NAND, then the vendor/customer can get
> drives with gooduns rather than baduns. Not necessarily a quick fix, but
> knowing the quality of the NAND in the SSD you're planning to buy matters.
OK, now I see the difference. Still, it'll be quite difficult to find out
which NAND manufacturers are good, especially when the drive manufacturer
may use more of them at the same time. And as David Boreham pointed out,
we don't know why the drives actually failed :-(
>>> Also, given that PG is *nix centric and support for TRIM is win
>>> centric,
>>> having that makes a big difference in performance.
>>
>>Windows specific? What do you mean? TRIM is a low-level way to tell the
>>drive 'this block is empty and may be used for something else' - it's
>> just
>>another command sent to the drive. It has to be supported by the
>>filesystem, though (e.g. ext4/btrfs support it).
>
> My point. The firmware and MS have been faster to support TRIM than *nix,
> linux in particular. Those that won't/can't move to a recent kernel don't
> get TRIM.
Faster? Windows 7 was released on October 2009, Linux supports TRIM since
February 2010. That's about 3 or 4 months difference - given that it may
easily take a year to put a new OS / kernel into a production, it's
negligible difference. For example most of the corporations / banks I'm
working for are still using Windows XP.
Don't get me wrong - I'm not blindly fighting against Windows, I just
don't see how this makes the TRIM a windows-specific feature.
Tomas
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: tv@fuzzy.cz, gnuoytr@rcn.com
Subject: Re: Reports from SSD purgatory
In-Reply-To: <7fb128a72b9945f6b905d563c67ebffc.squirrel@sq.gransy.com>
* 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