From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Fri,  6 Mar 2009 22:01:29 -0500
From: William Josephson <jkw@eecs.harvard.edu>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Message-ID: <20090307030128.GA64231@mero.morphisms.net>
References: <20090305035504.GA45687@mero.morphisms.net>
	<9564059c62184de78c3b50f1341858db@quanstro.net>
	<20090305041633.GA45971@mero.morphisms.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20090305041633.GA45971@mero.morphisms.net>
User-Agent: Mutt/1.4.2.3i
Subject: Re: [9fans] threads vs forks
Topicbox-Message-UUID: b5346876-ead4-11e9-9d60-3106f5b1d025

On Wed, Mar 04, 2009 at 11:16:33PM -0500, William K. Josephson wrote:
> On Wed, Mar 04, 2009 at 11:00:25PM -0500, erik quanstrom wrote:
> > > On Wed, Mar 04, 2009 at 10:32:55PM -0500, J.R. Mauro wrote:
> > > > What types of things degrade their performance? I'm interested in
> > > > seeing other data than the handful of benchmarks I've seen. I imagine
> > > > writes would be the culprit since you have to erase a whole block
> > > > first?
> > >
> > > Being full.  Small random writes, too, although much more so for
> > > run-of-the-mill SSDs than for FusionIO.
> >
> > [citation needed]
>
> Not really.

To be less flippant, what makes high performance flash difficult
is the slow erasure time and large erasure blocks relative to
the size of individual flash pages.  Being full hurts since the
flash is typically managed by a log structured storage system
with a garbage collector.  Small random writes require updating
the logical->physical mapping efficiently and crash recoverably.
You also need to do copy-on-write which leads to what is commonly
called write amplification, which reduces the usuable number of
writes.  Small writes tend to exacerbate a lot of these problems.

Where does all this fancy stuff belong?  In the storage medium,
in the HBA, in the device driver, in the file system, or in the
application?