Ask Your Question

Optimization for an SSD?

asked 2014-02-16 18:26:08 -0500

haziz gravatar image

updated 2014-09-28 18:29:36 -0500

mether gravatar image

I am running Fedora 20 on a Laptop ( Lenovo Ideapad Yoga 2 Pro ) with an SSD. My filesystem is LVM with ext4 as the format option. I am now running Fedoras as the only OS on the system with Legacy BIOS turned on (the system came configured as Secure Boot) and with the entire hard drive reformatted for Fedora.

What optimizations should I institute to ensure long, and trouble free, SSD life?

edit retag flag offensive close merge delete


What is the current status with SSD's on Fedora 23? Are these answers here still correct? Anyone with a tip to an up-to-date guide on this topic? Thanks

hannsandersson gravatar imagehannsandersson ( 2015-11-19 17:47:57 -0500 )edit

8 Answers

Sort by » oldest newest most voted

answered 2014-02-17 05:53:17 -0500

NickTux gravatar image

updated 2015-01-06 02:10:11 -0500

Because I have an SSD and because the technology is changing rapidly (Linux too) , I will write what I have done in my SSD in order to reduce the writes (extend lifetime) and also use the TRIM option.

This is what I've done in Fedora 20 and can be considered as reliable, on Fedora 20.

To reduce the writes (equals to extend the lifetime) on SSD.

1) Mount the /tmp and /var/log/ directories to tmpfs. That way you will send all the contents in RAM , so be aware that you will not have any persistent contents under the /var/log/ directory after a reboot. The /tmp/ directory is for temporary files, so it doesn't matter.

Open the /etc/fstab file and with root user privileges and add two lines that will help to achieve this.

su - 
gedit /etc/fstab

and add the following lines

#SSD optimization, /var/log/ to RAM
none              /var/log/              tmpfs   size=10%                 0       0

#SSD optimization,  /tmp to RAM 
none             /tmp/                   tmpfs   size=10%                 0       0

If you have any problems with SELinux after a reboot, you should consider to remove the /var/log/ line from fstab or run the command sudo /sbin/restorecon -v /var/log .

2) Force Firefox to use memory cache (instead of disk 's cache)

At the URL bar, write about:config and click "Ok I'll be careful, I promise". Then at the search bar write: browser.cache.disk (as you see it here). Click on [browser.cache.disk.enable] and set it to false. At these (later) versions of Firefox the [browser.cache.memory.enable] is set to true by default so you don't need to do something here, but you must add a new key in order to define a value for the limit. I suggest to set a value of -1 to no limit at all, but use the space as needed. So, right click on the empty area and click on New → Integrer. As a name give browser.cache.memory.capacity and as a value -1 . That's it with Firefox. Check the following picture for a comparison.

image description

Call the fstrim system binary to TRIM the SSD weekly.

3) Enable fstrim (TRIM) in user space , (rather than kernel space).

You should definitely choose a filesystem that supports TRIM. ext4 is preferred, as reliable and stable.

Check if your disk supports TRIM , execute the following command and replace /dev/sda with the SSD 's letter.

su -c 'hdparm -I /dev/sda' | grep TRIM

it must return something like Data Set Management TRIM supported. If yes, then add the following script inside the file /etc/cron.weekly

As of Fedora 21 the following script is not needed. As @fxx pointed out in commends below, there is a new service unit included in F21, which will allow to enable fstrim through a timer unit. Check this post here and enable fstrim through systemd.

sudo systemctl enable fstrim.service
# call fstrim to trim the specified ...
edit flag offensive delete link more



1 and 2 are viable and valid options for all installs where there is plenty of memory. As I run with an external firewall/squid box, I turned down my local caching on Firefox anyway.

I always through 3 was done automatically by the innards of the ssd device. Perhaps I'm wrong... I feel a bit of reading-up coming on.

cobra gravatar imagecobra ( 2014-02-17 08:33:50 -0500 )edit

Define "plenty of memory". I think that 3GBs or more are enough. As for the TRIM, this definitely should happen in kernel space, but as of now (as far as I know) there is no such option implemented (at least in Fedora 20 kernel 3.11). So I use the fstrim user space tool to achieve this (to be sure I mean). The discard option is the kernel option for the same function, but I've read that has had more disadvantages than the opposite.

NickTux gravatar imageNickTux ( 2014-02-17 09:02:14 -0500 )edit

'plenty of memory' is quite transient. About 18 months ago, I was finding computers with 2GB of memory were now using small amounts of swap with Fedora. That's really the minimum these day, but new computers come with much more anyway, and only my Eee pc now has 2GB memory, all the others I support have more.

cobra gravatar imagecobra ( 2014-02-17 09:42:19 -0500 )edit

Could you correct the section on fstrim? Arch wiki says "The partition for which fstrim is to be applied must be mounted, and must be indicated by the mount point. " Issuing the command like you proposed gives e.g. /dev/sda2: not a directory error. I tried reading man fstab but the verbose section is poorly written. Also after issuing fstrim -v / I got FITRIM ioctl failed error.

Bucic gravatar imageBucic ( 2014-02-19 13:42:36 -0500 )edit

As you've searched the ArchLinux wiki, if you have any encrypted partition you must specify a parameter in grub/kernel.. see here. If you have LVM setup, you must enable trim support for LVM through a parameter in grub/kernel (again) issue_discards = 1 . My answer couldn't cover all the possible filesystems and setups. It is a general answer for an ext4 filesystem. Without crypt or LVM setups. I've corrected the typo with the mountpoint. Thanks

NickTux gravatar imageNickTux ( 2014-02-19 17:26:42 -0500 )edit

answered 2014-02-17 04:23:07 -0500

Bucic gravatar image

updated 2014-02-17 04:33:41 -0500

There are quite a few tweaks/usage considerations actually. Here's a comprehensive list of things you can do:
Setting up and using SSD drives in Fedora Linux
though only select tweaks actually make a big difference, e.g. disabling ext4 file system writes, making sure torrent files and browser cache is not being written to your ssd, making sure each partition of your SSD has at least ~20% of free space.

On the other hand contemporary SSD's are quite durable even if abused. Looking for SSD life info

edit flag offensive delete link more



This is an old guide. Doesn't apply nowadays. discard option is not needed , in some ways it is considered as a bad option (after some tests I read over the Web). Better to use fstrim for now. Good options are the /tmp and maybe /var/log on tmpfs to reduce SSD writes. Also, the [cfq] scheduler is very reliable and good for SSDs , there is no need for elevator=noop. Additionally, the doesn't even exist in Fedora 20 (by default I mean).

NickTux gravatar imageNickTux ( 2014-02-17 04:48:55 -0500 )edit

Fedora now automatically mounts /tmp to tmpfs

singlechair gravatar imagesinglechair ( 2015-12-09 15:22:27 -0500 )edit

@singlechair: Really? Meaning /tmp goes to RAM?

hannsandersson gravatar imagehannsandersson ( 2015-12-10 22:12:13 -0500 )edit

I read somewhere (don't remember where) that this is now the default (ie: /tmp type tmpfs). I confirmed this to be the case on my system running: $ mount | grep -i tmp

singlechair gravatar imagesinglechair ( 2015-12-18 10:17:40 -0500 )edit

@singlechair: Maybe starting with Fedora 23. On my Fedora 22 Workstation system I still had to put a line

none             /tmp/                      tmpfs   size=8% 0 0

to /etc/fstab

hannsandersson gravatar imagehannsandersson ( 2016-01-20 09:08:42 -0500 )edit

answered 2017-05-29 13:36:29 -0500

rugk gravatar image

updated 2017-05-30 09:07:55 -0500

Many answers here are quite outdated and this offer obsolete or even bad advice. Also the official guidelines do not offer much advice. So first, we assume a modern Fedora installation, which thus uses LVM and maybe even dm-crypt/LUKS for encryption.


So TRIM is very useful and you should usually set it up, but do not just add discard to your fstab file. Better run fstrim regularly as this sends all this information about deleted files (blocks) in "one go" and not after each file deletion. For a good & detailed guide see this awesome blog post, which has been recommended by @hannsandersson.

Note that Fedora delivers a basic service for doing so by default. It just runs fstrim -a, which means it tries to trim all devices and does not show an error, when it cannot trim a device.

$ cat /usr/lib/systemd/system/fstrim.service
Description=Discard unused blocks

ExecStart=/usr/sbin/fstrim -a

It is, however, disabled by default (at least in my case):

$ sudo systemctl status fstrim
● fstrim.timer - Discard unused blocks once a week
   Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; disabled; vendor preset
   Active: inactive (dead)
     Docs: man:fstrim

But you can enable it – as usual – like any other systemd service: sudo systemctl enable fstrim. Then it should run weekly (see the timer file at /usr/lib/systemd/system/fstrim.timer).

In the blog I linked earlier, you, however, also see that enabling TRIM with dm-crypt can be dangerous, as it leaks some information, so you have to decide what is more important here.


In new Fedora versions it does not seem to be required to set /tmp as a temp file system (tmpfs) in etc/fstab. You can run df to see your file systems and you should see /tmp/ using tmpfs there. If you're lazy you can also grep it ;) :

$ df | grep /tmp 
tmpfs                              404[…]     160   404[…]  1% /tmp

Honestly, I have no idea why it does not have an entry in /etc/fstab and works anyway… (So if you have any clue here, please comment.)


As for log files, this is of course your decision. If you think they are not important, move them to a temp file system or so. At the end I mention a way how to force a volume to go to the HDD when both are in one LVM group.

application caches

Scrolling around on this page, you'll also see some advice about disabling the Firefox disk cache. If you want to do so so, do so, but be aware that doing so might slow down some web loads and might not be the best experience – especially as caches need to be accessed fast and a SSD may not be the worst storage for them. This is discussable, however. In any case you could do the same for ~/.cache and other caches. This could be cumbersome and you need to evaluate, whether it is worth ... (more)

edit flag offensive delete link more


In Fedora 27 it seels you should sudo systemctl enable fstrim.timer.

Willtech gravatar imageWilltech ( 2018-04-18 14:37:38 -0500 )edit

answered 2016-03-11 21:09:23 -0500

Something that could help somebody partitioning to install Fedora on SSD & HDD. From

A Good SSD/HDD Partitioning Scheme

An SSD is a great investment. Data loads super fast and there are no moving parts to fail. But SSD storage space is expensive, and most users have a lot to store. A common solution is to install the OS to the SSD, and move personal data (the /home directory) to a secondary HDD. While this is the easiest way to take advantage of SSD speed, the results are less than ideal. SSDs have a limit on write cycles so it is wise to minimize disk write operations. My preferred solution offloads some of the more volatile areas of the Linux filesystem to the HDD as well.

The table below shows how I partitioned my 32GB SSD (/dev/sda) and my 320GB HDD (/dev/sdb):

Partition Size Type Mount Point /dev/sda1 512M ext4 /boot /dev/sda3 23.5G ext4 / /dev/sda5 8G ext4 /usr

/dev/sdb1 4G ext4 /var /dev/sdb2 4G swap /dev/sdb5 192G ext4 /home (120GB Unpartitioned space on /dev/sdb)

This scheme takes advantage of the SSD’s speed in areas that matter, while making sure to maximize its lifespan by minimizing write cycles. Below we’ll take a look at each partition in more detail. The /boot Directory

A long-standing convention states that /boot should be its own small partition at the front of the disk. This goes back to old BIOS limitations which no longer apply. Nevertheless, I prefer to maintain this convention because it’s familiar and logical. Some Linux admins keep /boot on its own partition so that it can remain unmounted by the running system for security reasons. This is possible because the files in /boot, while accessed by the bootloader, are generally ignored by the kernel and other processes. If you do this, it is good to leave a /boot entry in /etc/fstab so that the partition can be easily mounted for such tasks as bootloader configuration and kernel image updates, but append the noauto option to prevent the kernel from automounting the partition on boot.

Note: Before you decide to leave your /boot directory unmounted, consider the following. Many package managers include kernel updates as part of their normal update process. If your package manager does this, it will likely write the updated kernel image to the empty placeholder /boot directory on the root partition, but GRUB will still try to read the kernel image from the /boot partition (remember that GRUB uses its own syntax to refer to filesystems), and thus will fail to find the appropriate kernel image. Don’t do this unless you know what you are getting into, or if your distribution is such that you build and install your own kernel images rather than relying on a package manager to do it.

It is worth pointing out that only very recent versions of GRUB support the ext4 filesystem ... (more)

edit flag offensive delete link more

answered 2017-08-18 19:46:53 -0500

lsatenstein gravatar image

I have an SSD and I read that btrfs is better than ext4 for the SSD. It has to do with meta data writes and journaling.

btrfs uses copy on right. To write data, it reads the appropriate SSD blocks (if any data and meta data), it writes the data, to a new location. It then writes the updated meta data and changes a pointer.

For ext4, you have journaling to contend with in addition to rewriting data. It seems that btrfs is easier on the SSD than is ext4 or xfs.

I also do the following. I create an entry in the root crontab that appears as follows.

@reboot /sbin/fstab -a

I power up my system about once per day. Ergo, on a reboot, I have a fstrim run.

There is also a systemd fstrim.service which writes a file that has a timestamp. There is a timer that is verified on a count down basis or on a reboot. When the time has elapsed, a fstrim -a is executed (typically once a week).

edit flag offensive delete link more

answered 2014-07-31 04:10:25 -0500

edine gravatar image

If you are using a Crucial SSD, the garbage collector tool will do the trimming of the ssd, when the drive is idle or when you live the computer on bios for some time. (According to Crucial Uk agents)

I suggest you open the terminal and just type:

su (Write your root password) fstrim -v / And then write too: fstrim -v /home

Or if you have enabled sudo sudo fstrim -v / And sudo fstrim -v /home These commands should do for an ssd with a standard lvm installation in Fedora 20. You can run this command once a day, or once a week, it should be more than enough, provided that you don't do any heavy work loads daily.

edit flag offensive delete link more

answered 2014-02-27 19:27:43 -0500

John Chen gravatar image

If you want to improve and tweak your Ubuntu, Linux Mint, Fedora, Centos or any linux distribution on ssd, this will help you

Enable TRIM

TRIM (Trim command let an OS know which SSD blocks are not being used and can be cleared)

Back up fstab first in case something wrong happen.

# cp /etc/fstab ~/fstab.bk

Edit fstab file

# nano /etc/fstab

Add discard to your ssd drives or partitions, after ext4

UUID=bef10b86-494d-41c6-aa46-af72cfba90fd / ext4 discard,errors=remount-ro 0 1
edit flag offensive delete link more



You better don't activate real-time trimming by adding discard to your fstab - this can decrease the performance of your SDD and also increase write access. Google for it, there is plenty of blogs on this topic, just to name one here

hannsandersson gravatar imagehannsandersson ( 2015-12-10 22:11:28 -0500 )edit

Excellent tutorial, the one you mention: Thanks

damonh gravatar imagedamonh ( 2016-03-11 10:19:54 -0500 )edit

answered 2017-08-18 19:55:09 -0500

lsatenstein gravatar image

updated 2017-08-18 19:57:56 -0500

It is best to use create the / directory as resident on a btrfs file system and /home as ext4 or xfs.

Search elsewhere as to the comparison between btrfs and ext4 for number of I/O operations for a single data write.

systemctl list-timers NEXT LEFT LAST PASSED UNIT ACTIVATES and we get amonst Mon 2017-08-21 00:00:00 EDT 2 days left Mon 2017-08-14 00:00:00 EDT 4 days ago fstrim.timer fstrim.service

systemctl enable fstrim.service

What I do that may not suit your purpose is I create a root crontab with the following entry

@reboot /usr/sbin/fstrim -a

Every time I reboot the system, fstrim will run. I reboot at most once per day.

edit flag offensive delete link more

Question Tools



Asked: 2014-02-16 18:26:08 -0500

Seen: 54,968 times

Last updated: Aug 18 '17