From: Steve Clark <sclark@netwolves.com>
To: Scott Carey <scott@richrelevance.com>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Greg Smith <gsmith@gregsmith.com>
Cc: Merlin Moncure <mmoncure@gmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Intel's X25-M SSD
Date: Wed, 24 Sep 2008 07:11:57 -0400
Message-ID: <48DA207D.6090000@netwolves.com> (raw)
In-Reply-To: <a1ec7d000809232125w52b1122ema21a9958814224b2@mail.gmail.com>
References: <Pine.GSO.4.64.0809192316340.19112@westnet.com>
<200809240324.m8O3Ovn06515@momjian.us>
<a1ec7d000809232125w52b1122ema21a9958814224b2@mail.gmail.com>
Scott Carey wrote:
> A fantastic review on this issue appeared in July:
> http://www.alternativerecursion.info/?p=106
> And then the same tests on a RiData SSD show that they are the same
> drive with the same characteristics:
> http://www.alternativerecursion.info/?p=276
>
> Most blamed it on MLC being "slow" to write compared to SLC.
> Technically, it is slower, but not by a whole lot -- we're talking a low
> level difference of tens of microseconds. A 250ms latency indicates an
> issue with the controller chip. SLC and MLC share similar overall
> performance characteristics at the millisecond level. The truth is that
> MLC designs were low cost designs without a lot of investment in the
> controller chip. The SLC designs were higher cost designs that focused
> early on on making smarter and more expensive controllers. SLC will
> always have an advantage, but it isn't going to be by several orders of
> magnitude like it was before Intel's drive appeared. Its going to be by
> factors of ~2 to 4 on random writes in the long run. However, for all
> flash based SSD devices, there are design tradeoffs to make. Maximizing
> writes sacrifices reads, maximizing random access performance reduces
> streaming performance and capacity. We'll have a variety of devices
> with varying characteristics optimal for different tasks.
>
> On Tue, Sep 23, 2008 at 8:24 PM, Bruce Momjian <bruce@momjian.us
> <mailto:bruce@momjian.us>> wrote:
>
> Greg Smith wrote:
> > On Mon, 8 Sep 2008, Merlin Moncure wrote:
> >
> > > What's interesting about the X25 is that they managed to pull the
> > > numbers they got out of a MLC flash product. They managed this
> with a
> > > DRAM buffer and the custom controller.
> >
> > I finally found a good analysis of what's wrong with most of the
> cheap MLC
> > drives:
> >
> >
> http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3403&p=7
> <http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3403&p=7;
> >
> > 240ms random write latency...wow, no wonder I keep hearing so
> many reports
> > of cheap SSD just performing miserably. JMicron is one of those
> companies
> > I really avoid, never seen a design from them that wasn't cheap junk.
> > Shame their awful part is in so many of the MLC flash products.
>
> I am surprised it too so long to identify the problem.
>
> --
> Bruce Momjian <bruce@momjian.us <mailto:bruce@momjian.us>>
> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + If your life is a hard drive, Christ can be your backup. +
>
> --
> Sent via pgsql-performance mailing list
> (pgsql-performance@postgresql.org
> <mailto:pgsql-performance@postgresql.org>)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>
>
Anybody know of any tests on systems that have specific filesystems for
flash devices?
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: sclark@netwolves.com, scott@richrelevance.com, bruce@momjian.us, gsmith@gregsmith.com, mmoncure@gmail.com
Subject: Re: Intel's X25-M SSD
In-Reply-To: <48DA207D.6090000@netwolves.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox