From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <48b6abbc3c8630483d7867a2f9984f3a@quanstro.net>
From: erik quanstrom <quanstro@quanstro.net>
Date: Fri,  6 Mar 2009 22:31:59 -0500
To: 9fans@9fans.net
In-Reply-To: <20090307030128.GA64231@mero.morphisms.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] threads vs forks
Topicbox-Message-UUID: b538dcd0-ead4-11e9-9d60-3106f5b1d025

> 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?

it's interesting to note that the quoted mtbf numbers for ssds is
within a factor of 2 of enterprise hard drives.  if one considers that
one needs ~4 ssds to cover the capacity of 1 hard drive, the quoted
mtbf/byte is worse for ssd.

the obvious conclusion is that if you think you need raid for hard
drives, then you also need raid for ssds.  at least if you believe the
mtbf numbers.

i think that it's a real good question where the fancy flash
tricks belong.  the naive guess would be that for backwards compatability
reasons, the media will get much of the smarts.

- erik