Message-ID: <7fb128a72b9945f6b905d563c67ebffc.squirrel@sq.gransy.com>
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>
Date: Wed, 24 Aug 2011 22:10:28 +0200
Subject: Re: Reports from SSD purgatory
From: "Tomas Vondra" <tv@fuzzy.cz>
To: gnuoytr@rcn.com
Cc: pgsql-performance@postgresql.org
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
Importance: Normal

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