Re: SSD + RAID - Mailing list pgsql-performance

From Greg Smith
Subject Re: SSD + RAID
Date
Msg-id 4B8329A3.4040003@2ndquadrant.com
Whole thread Raw
In response to Re: SSD + RAID  (Arjen van der Meijden <acmmailing@tweakers.net>)
Responses Re: SSD + RAID
List pgsql-performance
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


pgsql-performance by date:

Previous
From: Joel Jacobson
Date:
Subject: Re: plpgsql plan cache
Next
From: Mark Mielke
Date:
Subject: Re: SSD + RAID