Message-ID: <4B8329A3.4040003@2ndquadrant.com>
Date: Mon, 22 Feb 2010 20:04:35 -0500
From: Greg Smith <greg@2ndquadrant.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Arjen van der Meijden <acmmailing@tweakers.net>
CC: pgsql-performance@postgresql.org
Subject: Re: SSD + RAID
References: <201002211410.o1LEAht05941@momjian.us>
	<4B814920.1040204@cheapcomplexdevices.com>
	<4B82187A.7060604@2ndquadrant.com> <4B822DFF.50501@tweakers.net>
In-Reply-To: <4B822DFF.50501@tweakers.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Arjen van der Meijden wrote:
> That's weird. Intel's SSD's didn't have a write cache afaik:
> "I asked Intel about this and it turns out that the DRAM on the Intel 
> drive isn't used for user data because of the risk of data loss, 
> instead it is used as memory by the Intel SATA/flash controller for 
> deciding exactly where to write data (I'm assuming for the wear 
> leveling/reliability algorithms)."
> http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3403&p=10

Read further down:

"Despite the presence of the external DRAM, both the Intel controller 
and the JMicron rely on internal buffers to cache accesses to the 
SSD...Intel's controller has a 256KB SRAM on-die."

That's the problematic part:  the Intel controllers have a volatile 
256KB write cache stored deep inside the SSD controller, and issuing a 
standard SATA write cache flush command doesn't seem to clear it.  Makes 
the drives troublesome for database use.

> I can understand a SSD might do unexpected things when it loses power 
> all of a sudden. It will probably try to group writes to fill a single 
> block (and those blocks vary in size but are normally way larger than 
> those of a normal spinning disk, they are values like 256 or 512KB) 
> and it might loose that "waiting until a full block can be 
> written"-data or perhaps it just couldn't complete a full block-write 
> due to the power failure.
> Although that behavior isn't really what you want, it would be 
> incorrect to blame write caching for the behavior if the device 
> doesn't even have a write cache ;)

If you write data and that write call returns before the data hits disk, 
it's a write cache, period.  And if that write cache loses its contents 
if power is lost, it's a volatile write cache that can cause database 
corruption.  The fact that the one on the Intel devices is very small, 
basically just dealing with the block chunking behavior you describe, 
doesn't change either of those facts.

-- 
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com   www.2ndQuadrant.us