---- Original message ----
>Date: Wed, 24 Aug 2011 11:25:27 -0600
>From: pgsql-performance-owner@postgresql.org (on behalf of David Boreham <david_list@boreham.org>)
>Subject: Re: [PERFORM] Intel 320 SSD info
>To: pgsql-performance@postgresql.org
>
> On 8/24/2011 11:23 AM, Andy wrote:
>
> According to the specs for database storage:
> "Random 4KB arites: Up to 600 IOPS"
> Is that for real? 600 IOPS is *atrociously
> terrible* for an SSD. Not much faster than
> mechanical disks.
>
> The underlying (Flash block) write rate really is
> terrible (and slower than most rotating disks).
At the lowest physical level, yes. It's much simpler to flip the flux in the rust (I know, they've moved on from rust,
butI can't give up the image) than to change state in NAND. But that's hardly the point.
>
> The trick with SSD is that firmware performs all
> kinds of stunts to make the performance seen
> by the OS much higher (most of the time !).
It's not an illusion. Check the AnandTech (or Tom's or whoever you prefer) tests for sequential speeds vs. HDD. You
mayhave to go back a year or so, since they've mostly stopped trying to graph HDD and SSD at the same time. Random is
aworse comparison for HDD. Yes, there are legitimate issues with power loss, especially in consumer and prosumer
drives. That's why STEC and Violin and Fusion-io and Texas Memory exist. Whether bespoke controllers will continue to
beshipped is up in the air. At one time mainframes had bespoke DASD. Not for more than a decade; they run on the same
HDDyou can buy at Newegg; better QA, but the same drive.
> This is
> akin to write-back caching in a raid controller,
> for example, where much higher write rates than the
> physical drives support are achievable.
Not really. Some SSD have lots o RAM cache, others have none at all (notably, SandForce controller). See this:
http://www.storagesearch.com/ram-in-flash-ssd.html