Skip site navigation (1) Skip section navigation (2)


From: Mark Mielke <mark(at)mark(dot)mielke(dot)cc>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: Arjen van der Meijden <acmmailing(at)tweakers(dot)net>, pgsql-performance(at)postgresql(dot)org
Subject: Re: SSD + RAID
Date: 2010-02-23 01:11:26
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
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)."
> 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?


In response to


pgsql-performance by date

Next:From: Greg SmithDate: 2010-02-23 01:14:47
Subject: Re: SSD + RAID
Previous:From: Greg SmithDate: 2010-02-23 01:04:35
Subject: Re: SSD + RAID

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group