[ltp] ssd+tricks, performance

Robert Tomsick linux-thinkpad@linux-thinkpad.org
Tue, 18 Nov 2014 15:07:10 -0500

On Tue, Nov 18, 2014, at 02:14 PM, Uwe Brauer wrote:
> There are a lot of articles about what are the best tricks to enhance
> performance and life span of a SSD disk (Paul recently posted quite a
> bunch).
> (I have a Samsung 840 (no pro) installed)
> Things I am relative sure about:
> [... snip ...]
> In my fstab?? It seems that my Kubuntu 10.04 does not ship tmpfs so I
> should compile it myself.
> Any comments?

One comment: 

Ignore them.

Seriously.  Unless you're trying to win a benchmark competition there is
absolutely no need to do any tweaks of any sort for SSDs, with the
possible exception of enabling TRIM support manually (if required by
your distro.)

The very, very first generation products (c. 2008/2009) had some pretty
big flaws that could be (partially) avoided via the use of certain
tweaks.  This, coupled with the fact that several key pieces of the
stack assumed that they'd be running on spinning rust, meant that there
were some real benefits to a few of the tweaks that became popular.

Unfortunately, these "tweaks" have only grown in popularity among
various enthusiast groups over the last 5 years and are often repeated
as things you "must" do to achieve optimal performance or avert
catastrophe, despite them being necessary for neither.

Unless you have supporting data to the contrary, just stick with your FS
defaults.  Samsung is a multi-billion dollar company that has teams of
engineers working to make their drives perform optimally with modern
filesystems.  Do you really think that a couple of wiki authors or forum
posters can come up with a couple lines of "fixes" that provide a
measurable improvement?  And if they do, are you really comfortable with
the trade-offs that they make?  Are you confident that they even
understand what those trade-offs are?  

Most of the tweaks don't do much of anything, but some are measurably
harmful.  Using JFS for example, is a fine choice if you have a specific
need for it.  If you don't, well, then you've just given up all of the
data integrity improvements and the rigorously codebase that EXT4 offers
in exchange for nothing.

Disabling atime altogether is fine... unless you use software that
depends on it, in which case you break things.

What about schedulers?  Well... noop/deadline *was* a better choice than
CFQ for some specific drives when mainstream SSDs were first introduced.
 But after 5+ years of them being on the marketplace, CFQ hasn't stood
still -- and it now knows about non-rotational media (i.e. SSDs) and
adjusts its algorithm accordingly.  So again: unless you have a specific
case that you know about where CFQ isn't a good scheduler, I'd stick
with it.

Basically, unless you have evidence that the defaults aren't acceptable
performance-wise, I'd stick with them.  Just because you have an SSD
doesn't change that.  Defaults tend to be picked for a reason: they
provide safe, reliable operation that meets the needs of most users --
and I have very rarely seen a case where they didn't suffice for your
typical desktop user.