
Coding for SSDs - dedalus
http://codecapsule.com/2014/02/12/coding-for-ssds-part-1-introduction-and-table-of-contents/
======
danielvinson
As somebody who worked on SSDs here is my commentary:

1\. Most of the recommendations are things that will have little to no benefit
on any modern SSD because all of this is handled for you in the firmware. When
SSD firmware is not perfectly optimizing your performance, it is doing so to
extend the life of the drive. Take this with a grain of salt though since many
SSD manufacturers use really bad code provided by the controller manufacturer
(SandForce notably provided awful stock firmware).

2\. SSD benchmarks commentary is mostly accurate - since performance is very
motherboard chipset-dependent, we chose the best ones to publish. Can't really
blame anyone, but it means that if you bought the drive you are incredibly
unlikely to achieve identical performance.

3\. "Benchmarks are hard". No, not really. I wrote most of the benchmarks we
used for linux testing. The reason benchmarks could be considered difficult is
because all of the internal benchmarks that are used were written in-house and
not released to the public. Reviewers never really had the right tools.

4\. Enterprise SSDs and Consumer SSDs are drastically different. If you want
consistent high performance, get an enterprise PCI-X drive. NAND quality is
the major difference... and good NAND is hard to find. Generally an enterprise
SSD will also have a significantly faster controller, and on larger drives,
will contain more than one controller to avoid straining resources.

~~~
DannoHung
So, unlike doty said below, we _shouldn 't_ treat SSDs like a faster form of
spinning rust?

Where do we find real advice about how to best utilize SSD?

~~~
baruch
There is unfortunately no good place to do that.

I work in an enterprise setting and get to talk to the ssd vendors and fish
for details on how to best use their ssds and I still find it hard to get full
information. Sometimes I wonder if there can even be a single compendium of
knowledge about ssds. There are just so many moving parts in there that I
doubt the ssd vendors themselves know what is really happening. Many times
there are strange behaviors that we hit and then the vendors get to debug
their ssds and explain new things about what just happened.

One effect that I can attest to is that I know quite a bit about the ssd
inner-workings (or at least how it shows to the outside world, never saw an
ssd firmware source line) but it would be very hard for me to sit down and
write something about all aspects. I can however answer questions when needed.

~~~
joshuacc
> There are just so many moving parts

I found this amusing in the context of SSDs versus spinning rust. :-D

~~~
baruch
Indeed :-)

If you really want to be pedantic, there are electrons moving in there so it
is solid state but it has moving parts :-)

------
doty
What's interesting to me is that if you read the summary
([http://codecapsule.com/2014/02/12/coding-for-ssds-
part-6-a-s...](http://codecapsule.com/2014/02/12/coding-for-ssds-
part-6-a-summary-what-every-programmer-should-know-about-solid-state-
drives/)), most of the recommendations are exactly the same as when
programming against a traditional spinning-oxide hard drive: read and write
entire blocks if you can, combine block writes, &c.

It's nice to know that all that work on high-performance IO in databases
doesn't need to be thrown away just yet.

~~~
nqzero
this is true because the NAND has been crippled by imposing the FTL on it. if
you could bypass the FTL, then the programming advice would be quite
different, and if properly applied result in much better long term performance

~~~
pkaye
In what way would you do it differently than the FTL. Are you familiar with
all the restrictions and limitations of using NAND and how it impacts the FTL
algorithms?

~~~
nqzero
it's less that i'd do things not currently done in the FTL, and more that it
would be deterministic. my algorithm is a cyclic cache that's write heavy, at
least initially targeted at low end hardware. if i could bypass the FTL, i
could ensure that my algorithm wasn't amplifying. but with FTL, which varies
from drive to drive, my usage pattern could result in a great deal of
amplification

i'm sure that for any given controller's FTL (and this article claims that
there really are only a couple on the market), i could tweak my algorithm to
work reasonably well. but that's a sign of a leaky abstraction

i'd also like access to the small SLC portion of the drive, though i'm working
around that for now with journaling

i'm not an expert in flash memory. my model is basically a block device with
larger block erasure, and that the number of erasures each block can handle is
limited

------
barrkel
Part 6 in particular is a decent distillation of stuff to keep in mind that
should apply across SSDs from multiple vendors. It would be nice to have
benchmarks that validate the individual assertions, of course.

There's a lot of complexity going on behind the scenes of modern SSDs.
Simplistic benchmarks as posted on most review sites often don't address real-
world performance. The ones I pay most attention to are things like BootRacer;
it's quite remarkable how often a drive will be slower at booting Windows than
a competitor, even when it beats them in simple metrics like sequential /
random reads / writes with different queue depths.

I can see the potential for firmware being optimized for modalities that crop
up often in benchmarks but less often elsewhere: the aforementioned sequential
/ random reads and writes with different block sizes and queue depths. Doing
well on benchmarks probably drives a bunch of sales. But detecting and
switching modality may not be latency-free, and shortcuts taken to improve
absolute performance in those modalities may harm global performance in a
real-world IO mix.

~~~
polskibus
Do you have any links that would show that an SSD was tuned solely for
benchmark purposes? I know people have found such things in GPU market but
I've never heard about such claims in SSD market.

~~~
Kurtz79
"Back in the days many SSD vendors were only focusing on high peak
performance, which unfortunately came at the cost of sustained performance. In
other words, the drives would push high IOPS in certain synthetic scenarios to
provide nice marketing numbers, but as soon as you pushed the drive for more
than a few minutes you could easily run into hiccups caused by poor
performance consistency. Once we started exploring IO consistency, nearly all
SSD manufacturers made a move to improve consistency."

[http://www.anandtech.com/show/9144/crucial-
bx100-120gb-250gb...](http://www.anandtech.com/show/9144/crucial-
bx100-120gb-250gb-500gb-1tb-ssd-review/3)

------
rootedbox
"My only regret is not to have produced any code of my own to prove that the
access patterns I recommend are actually the best."

 _sigh_

