
SSD: How to Optimize Your Solid State Drive for Linux - ekianjo
https://sites.google.com/site/easylinuxtipsproject/ssd#TOC-Avoid-exaggerated-measures
======
simoncion
This pretty much all seems to be a lot of fiddly work that tries to reduce
writes to your SSD.

People Who Know in the industry know that any non-bottom-of-the-barrel SSD
bought in the last -like- five years or so will endure many tens of TBs of
writes.

If we look at Tech Report's SSD Torture Test [0], we know with some confidence
that consumer-level SSDs will endure _hundreds_ of TBs of writes before
failing.

To provide some perspective for those numbers: My Linux laptop has encrypted
swap, btrfs root partiton, and encrypted btrfs /home all on the SSD, and sees
frequent compiles-from-source (I run Gentoo Linux.). Other than mounting my
filesystems with the "discard" option, I've performed no SSD-specific
configuration step or fiddled with any VM tunables.

Under this workload and configuration, I have written 20.4TB and read 66.8TB
over 3.9 years. SMART indicates that zero blocks have been reallocated and
that the drive is in perfect health.

In short, if you've a consumer or developer's workload, _don 't worry_ about
SSD media longevity. Regardless of who you are, strongly consider benchmarking
any configuration tweaks that folks claim will improve performance.

[0] [http://techreport.com/review/27909/the-ssd-endurance-
experim...](http://techreport.com/review/27909/the-ssd-endurance-experiment-
theyre-all-dead) (But make sure to also check out the intro article:
[http://techreport.com/review/24841/introducing-the-ssd-
endur...](http://techreport.com/review/24841/introducing-the-ssd-endurance-
experiment) )

~~~
vacri
Supporting anecdata: I had a windows 7 gaming machine that saw a fair amount
of use each day, with the pagefile on an SSD, and no tuning. Took about four
years before the drive started failing (well, failing noticeably as a user).

~~~
arthurfm
> Took about four years before the drive started failing (well, failing
> noticeably as a user).

Was the SSD made by OCZ or had a Sandforce controller by any chance?

Also anecdotal, but my 160GB Intel X25-M 'G2' has been working perfectly for
the past 5 years and 10 months. So far I have written 16.92 TBs to it [1] and
until I moved the drive into another PC I had been running games and VMs from
it.

[1] [http://i.imgur.com/u3AfP9R.png](http://i.imgur.com/u3AfP9R.png)

~~~
simoncion
FWIW, the drive from which I quote usage stats in my comment is a 100GB OCZ
Vertex LE. So, this is the fabled "double whammy" of OCZ-manufactured drive
and early SandForce chip.

------
andmarios
This is bad advice imo. A SSD offers small capacity for a big price. It is a
bad match for preserving data. Its advantage is its speed, especially in seek
times, but also on read/write operations.

If one wants to “get his money back” the best way is to utilize the SSD to its
fullest instead of trying to preserve it for ten years. Write on it as much as
you can. Use it to make your system faster. Use it to hide your setup's
shortcomings.

Couple years back, I had only 8GB of RAM on my system. The first thing I did
when I got a SSD was to put the swap on it. The zero-seek times (compared to
HDDs) made the dreaded swap operations almost imperceptible. What worths more?
The SSD or the ability to do my work without hinders?

Other bad advice in the article:

    
    
      - Use noatime: this is old, use relatime.
      - Do not use btrfs: compression, deduplication, COW, snapshots etc are very useful for the small sized SSDs
      - Do not enable hibernation: Maybe we should return to windows '98
      - Disable browser cache: facepalm, just try browsing like this...
    

Ommited advice from the article:

    
    
      - Use part of the SSD as a cache for your HDDs (native support by LVM)
    

In short: do not try to protect your SSD. Try to kill it as fast as possible.
:)

~~~
ghshephard
It's fine as long as people know what they are doing is ridiculous. I have a
friend who both tries to hyper mile and as well as prevent any wear on his
brakes on his Diesel VW Golf TDI. As in, his objective is to never, ever touch
his brakes, or accelerate (significantly). He plans out his highway on-ramps
to avoid sudden acceleration, rarely passes, and gauges stop-lights blocks in
advance to reduce braking.

Is this _needed_ in a modern car, or does it make driving said care more
pleasurable, (or, for that matter, safe?) No, in call cases. But, he takes a
particular pleasure about taking his vehicle into the dealer (free, once a
year), and at 75,000 miles being told that his brakes look like they've got
10,000 miles on them.

So, if you read the advice on SSDs in this (ridiculous to some) vein, then
It's a fun read.

~~~
andmarios
Your friend's practice seems a bit excessive to me, though I can understand
one adopting some good driving habits to reduce wear and increase mileage. It
usually leads to more safe roads too, due to less aggressive driving
behaviour.

A thing I can't understand are screen protectors used by people with an office
job. The amount of R&D put into modern phones' screens and oleophobic coating
is huge. Your phone's screen is designed to withstand both hits and dirt, to
let your fingers slide with minimal friction and to allow you perceive every
last pixel of your QHD panel (which has its own huge amount of R&D). Why would
you miss all these by gluing a $5 piece of plastic on top of it?

~~~
keenerd
> Why would you miss all these by gluing a $5 piece of plastic on top of it?

Some of us prefer matte, non-mirror screens.

~~~
kuschku
Especially as those are also more fat-resistant. And read better in sunlight.
<3 matte screens.

------
cabirum
Ah, typical Linux article with an obligatory insult for Windows. Hope OP
realizes Windows disables defrag for SSDs, and basically does everything
described in the article without needing user intervention.

Next, you don't have to over-provision unpartitioned space AND preserve 20% of
partitioned free space. It's one or another, the point is to have enough free
space for proper wear leveling.

Hibernation can stay enabled, it just dumps RAM contents into a file, once.
SSDs are much more vulnerable to small frequent writes (log files, browser
cache, etc) due to write amplification and minimum write size
([http://www.ni.com/product-
documentation/10126/en/](http://www.ni.com/product-documentation/10126/en/)).

~~~
Zr40
I don't know about earlier Windows, but Windows 8 does not attempt to
defragment drives that identify themselves as being solid-state. It does
invoke TRIM on drives that advertise that feature, and confusingly, this is
done through the same defragmentation UI.

~~~
cabirum
Why 'confusingly'? It's only natural to keep drive maintenance in one place.
You don't ever need to invoke defrag/trim manually as they are scheduled to
run whenever PC is not in use.

~~~
Zr40
It's confusing to people who are told to disable defragmentation on SSDs. It's
the same button for both HDDs and SSDs, and both TRIM and defragmentation are
referred to using the same word, 'optimization'[0]. An unaware user would not
know the difference.

[0] [http://www.oszone.net/user_img/vadblog/ssd-defrag-bug-
en01_m...](http://www.oszone.net/user_img/vadblog/ssd-defrag-bug-
en01_mini_oszone.png)

------
joosters
_Enjoy your SSD carefree for years and years_

 _18\. Now you 'll be able to enjoy your SSD carefree!_

This should have been step 1. SSDs have a massive lifetime these days, you
don't need to do any of the other steps, some of them will even slow down your
computer.

~~~
philjohn
This.

The 850 Pro I've got in my machine has a stated write lifetime of 150TB.

And chances are, it'll do a lot more than that, it's just the number they'll
look at for the 10 year warranty.

------
tyfon
I feel that the arch linux wiki is the best resource for these problems.
[https://wiki.archlinux.org/index.php/Solid_State_Drives](https://wiki.archlinux.org/index.php/Solid_State_Drives)

Personally I just fully wipe a new ssd and put discard in fstab.

------
ars
I'm not sure the advice to disable the browser cache is such good advice.

~~~
ekianjo
Why is that? Provided you have sufficient RAM ?

~~~
baruch
The browser cache is about caching network resources and not about ram, pages
you visited yesterday are cached there and will have no place in ram.

------
ThatPlayer
There's also profile-sync-daemon [0] that moves browser profiles into a
ramdisk to save writing to/from the SSD all the time.

I think a copy-on-write filesystem like btrfs would be better on SSDs because
they do not change written data but rather write to a new area on the drive,
requiring less erases on the SSD's side.

There's also F2FS (Flash-Friendly File System) which has been in the Linux
kernel for a while now that specifically targets flash based drives.

Though I agree that most of these optimizations do not seem necessary on
modern SSDs.

[0] [https://github.com/graysky2/profile-sync-
daemon](https://github.com/graysky2/profile-sync-daemon)

~~~
baruch
F2FS is for direct NAND access, if you do it over an SSD that already has an
FTL (flash translation layer) you'll gain nothing and only cost extra writes.

~~~
ThatPlayer
I can't say I'm too familiar with it, but this article says F2FS specifically
targets the flash translation layer.

[https://lwn.net/Articles/518988/](https://lwn.net/Articles/518988/)

------
middleclick
I have been using an Intel 520 SSD on my Debian unstable for > 3 years and I
have not done any such setting let alone knowing they exist. Should I pay heed
or should I continue using my SSD like this? Thoughts?

~~~
ekianjo
I'd recommend to follow up at least on the post-installation tips, to reduce
swappiness and writes on the SSD drive. That way you can keep your SSD working
longer.

~~~
baruch
I wouldn't bother with any of this. The effects on the SSD are too low to be
worth it and there is no discussion on the tradeoffs that are being taken.
Disabling hibernation is really a shame for one. Trim is done excessively and
the benefit is not that big. The weekly trim should suffice and no need to do
it on boot.

I also doubt the disk scheduler is of any importance, as long as there are
enough IOs in the queue in the disk it will be fast, otherwise it will not.
All schedulers will allow multiple IOs in the queue for all I know.

I do the noatime for any system without regard if it is an SSD or HDD. I just
don't use atime at all to bother about the extra work needed to maintain it.

------
Supersaiyan_IV
Some SSD have problems executing fsync moderately fast - like the Crucial V4.
Here's the remedy:

[http://forum.crucial.com/t5/Crucial-SSDs/Solution-
Crucial-V4...](http://forum.crucial.com/t5/Crucial-SSDs/Solution-
Crucial-V4-runs-fast-in-linux-Benchmarks-Manual/m-p/162462#M45745)

------
legulere
I'd actually like some sources that BTRFS is bad for SSDs.

------
darklajid

        Copy/paste the following command line into the terminal:
        sudo mv -v /etc/cron.weekly/fstrim /fstrim
    

Uhm. What? That's how this article 'disables' a cron task? Why?

~~~
peletiah
Well, the author also insists to install gksu and leafpad.

------
moonbug
This, like most, advice from random websites, is a mixture of out-dated
notions half-truth and and outright wrong-headedness. Better to ignore it.

------
abricot
Use full drive encryption. Make backups and buy new drive when old one fails.
Done.

------
Theodores
What about SSHD drives - does Ubuntu have special drivers for them? Can I get
my code files to be on the SSD part of the SSHD drive or will they just be
allocated to the slow HDD part?

~~~
baruch
These devices do not expose their inner SSD and only utilize it as a cache.

You are probably better off with an SSD standalone or with a full blown SSD as
a block cache to the HDD in part and as a direct drive in the other part.

------
transfire
I like the idea of using my SSD as a HDD cache. What do others think?

~~~
baruch
It can work out nicely if most of what you do is the size of the SSD and the
total capacity is higher than the SSD capacity (i.e. lots of rarely used
stuff).

In fact, I worked on an enterprise storage that did just that and it
significantly improved performance for many workloads. There are open-source
solutions for that in Linux that integrate into LVM and do that pretty much
without any other interaction by the user. bcache comes to mind but there were
a few others as well.

------
ikonst
How recent is it? I see his BIOS screenshots are from a curved CRT.

~~~
ekianjo
It refers to Linux Mint 17.1 so this is updated fairly recently.

