Message-ID: <4B832B3E.9080207@mark.mielke.cc>
Date: Mon, 22 Feb 2010 20:11:26 -0500
From: Mark Mielke <mark@mark.mielke.cc>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.7) Gecko/20100120 Fedora/3.0.1-1.fc12 Thunderbird/3.0.1
MIME-Version: 1.0
To: Greg Smith <greg@2ndquadrant.com>
CC: Arjen van der Meijden <acmmailing@tweakers.net>,
	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>
	<4B8329A3.4040003@2ndquadrant.com>
In-Reply-To: <4B8329A3.4040003@2ndquadrant.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 02/22/2010 08:04 PM, Greg Smith wrote:
> 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 had read the above when posted, and then looked up SRAM. SRAM seems to 
suggest it will hold the data even after power loss, but only for a 
period of time. As long as power can restore within a few minutes, it 
seemed like this would be ok?

>> 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.
>

The SRAM seems to suggest that it does not necessarily lose its contents 
if power is lost - it just doesn't say how long you have to plug it back 
in. Isn't this similar to a battery-backed cache or capacitor-backed cache?

I'd love to have a better guarantee - but is SRAM really such a bad model?

Cheers,
mark