How to maximise SSD performance with Linux

How to maximise SSD performance with Linux


Now that SSDs have moved into the realm of affordability there’s little reason not to use one for your next PC if you’re not already using one. But Linux as with Windows has spent decades being tuned for spinning platter drives and while performance is noticeably increased when using an SSD under Linux there are a number of tweaks and filesystem changes you can do to make the most of your SSDs.

Filesystem layer

The first of these is easy to do and can both improve performance and more importantly the longevity of your SSD by reducing unnecessary writes (keeping in mind the memory used in SSDs has limited write-rewrite cycles).

By default many distributions including Ubuntu use the ‘relatime’ flag for updating file metadata when files are accessed but you’re unlikely to care about last access times. Additionally Linux supports TRIM with Ext4. TRIM is important for maintaining the performance of an SSD over time as files are added deleted and changed and lets the SSD know which blocks can be safely cleared. No distributions currently enable it by default but it’s simple to do by adding the ‘discard’ flag to any mounted SSDs.

To make all these changes open up a terminal and run:

sudo nano -w /etc/fstab

Then for all SSD devices in your system remove ‘relatime’ if present and add ‘noatimenodiratimediscard’ so it looks something like this:

/dev/sda   /   ext4   noatimenodiratimediscarderrors=remount-ro 0 1


The scheduler helps organise reads and writes in the I/O queue to maximise performance. The default scheduler in the Linux kernel is CFQ (Completely Fair Queuing) which is designed with the rotational latencies of spinning platter drives in mind. So while it works well for standard hard drives it doesn’t work so well when it comes to SSDs.

Fortunately the kernel comes with some other schedulers to play with and here the deadline and NOOP schedulers are ideal. Both are basic schedulers that guarantee fast turnaround of I/O requests. NOOP is basically no scheduler at all it’s a basic FIFO (First In First Out) queue whereas deadline does some sorting to guarantee read requests take priority over write which is useful if you want to guarantee read responsiveness under heavy writes.

Changing scheduler is easy and even better — you can do it on a per-device basis if you have a mixed SSD and spinning platter hard drive system using deadline for SSDs and CFQ for traditional drives. As CFQ is the default change SSDs to use deadline by opening up a terminal and running:

sudo nano -w /etc/rc.local

Then add the following line for each SSD in your system:

echo deadline >/sys/block/sda/queue/scheduler

Changing ‘sda’ to ‘sdb’ and so on for each SSD device. If you only have SSDs in your system you can instead set the global scheduler policy to apply to all devices at boot time.

For Ubuntu and other distributions using GRUB2 edit the /etc/default/grub file and add ‘deadline’ to the GRUB_CMDLINE_LINUX_DEFAULT line like so:

GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash elevator=deadline”

Then run ‘sudo update-grub2’.

Swap and tmp

Linux is pretty good at only using swap if it really needs to but even so if you’re installing to an SSD and you have a mechanical hard drive in your system be sure to put the swap partition on it instead of the SSD. If you’ve already installed Linux and allocated a swap partition on the SSD you can simply set aside a partition on a spinning platter drive and edit your /etc/fstab swap entry to point to it instead. For example assuming /dev/sdb is a normal hard drive:

/dev/sdb2   none   swap   sw  0 0

And reboot or alternatively issue ‘swapoff -a && swapon -a’ to update on the fly. If you have a purely SSD system and lots of memory you can disable swap almost entirely. Keep a swap partition available but add the following to your /etc/rc.local file:

echo 0 > /proc/sys/vm/swappiness

And Linux won’t use swap at all unless physical memory is completely filled.

Next to reduce unnecessary writes to the SSD move the temp directories into a ram disk using the ‘tmpfs’ filesystem which dynamically expands and shrinks as needed.

In your /etc/fstab add the following:

tmpfs   /tmp       tmpfs   defaultsnoatimemode=1777   0  0

tmpfs   /var/spool tmpfs   defaultsnoatimemode=1777   0  0

tmpfs   /var/tmp   tmpfs   defaultsnoatimemode=1777   0  0

If you don’t mind losing log files between boots and unless you’re running a server you can probably live without them also add:

tmpfs   /var/log   tmpfs   defaultsnoatimemode=0755   0  0

Considering that even everyday applications generate a lot of log files it’s not a bad idea to do this.


Any applications that write excessively to a hard drive are also candidates for moving data. Browsers are a fine example of this — the browser cache is nice but it’d work just as well from a spinning platter drive and save your SSD from thousands of writes a day that don’t make a huge difference to you.

To move the cache in Firefox in the browser type ‘about:config’ right-click anywhere and select New –> String and add ‘browser.cache.disk.parent_directory’. Edit the variable and point it to a directory on a non-SSD drive or if you don’t mind losing the cache between boots and you’re using the tweaks above point it to /tmp for a super-fast memory cache.

Moving the cache in Chrome is a little harder. The directory is hardcoded but you can use symbolic links to point it to a directory on another drive or to /tmp. You’ll find the cache under ~/.cache/chromium. You could also redirect the entire .cache directory as many programs use this for caching data.

Have a look at other applications you use and see if you can redirect any unnecessary writes as well.

Partition alignment

Finally there’s partition alignment but this can only be done with a clean system before you install either Linux or Windows. Partition alignment is critical for SSDs as being memory-based devices data is written and read in blocks known as pages. When partitions aren’t aligned the block size of filesystem writes isn’t aligned to the block size of the SSD causing extra overhead as data crosses page boundaries.

Aligning partitions is simply a matter of ensuring the first partition starts on a clean 1MB boundary from the start of the disk ensuring whatever block size the filesystem uses will align with the block size of the SSD (which can also vary). If you create partitions using Windows 7 on an empty drive it will start partitions at the 1MB boundary automatically.

In Linux simply run ‘fdisk -cu (device)’ on the drive you want to partition press ‘n’ for new partition ‘p’ for primary and enter a start sector of at least 2048. The general rule is that the starting sector must be divisible by 512 but to cater for all variations of SSD page size and filesystem block size 2048 is a good idea (and equates to 1MB).


  • Robin Jacobs

    Quite sure putting that in /etc/fstab would break it.

  • Joel Hinson

    2048 != 1mb

    • Nathan Hulse

      Correct, because blocks != megabytes.

    • Joaozito Polo

      a block = 512 bytes… 2048 blocks = 1mb

      • bertenvdb

        If a block = 512 B then 2048 blocks would be 1048576 B.
        So 1048576 B equals 1 MiB, not 1 MB! (certainly not 1mb)

        MB = Megabyte = 1000000 bytes
        MiB = Mebibyte = 1048576bytes
        mb = millibit… this unit doesn’t even exist

  • J_a_s_o_n

    You are irresponsible. Your mount lines are missing a bunch of commas. None of those mount lines will work. You’re going to screw up a lot of people.

  • pdffs

    This article is dangerously broken since the fstab lines have had various characters stripped, please correct or remove – anyone who follows this advice will end up with a system that doesn’t boot.

  • Simone Padovan

    defaultsnoatimemode=1777 … these lines CANNOT work!!! please fix your page!!!! like this “defaults,noatime,mode=1777

  • Calliope Technicolor

    Swappiness set to 0 on newer kernels disables swap entirely. It is better to use a low number (i.e. 10) than 0, but as-is (default of 60) the kernel only performs anticipatory swaps when memory starts to get quite low and there is a risk that it will soon run out. Very low swappiness will throw things out of the disk caches aggressively as memory fills up; it is often better to swap a small amount of almost-never-used memory pages to the SSD rather than dumping the caches in RAM before swapping, especially if you have ANY rotational or slow media (i.e. external hard drive, USB 2.0 flash drive) connected.

    What I’ve done with new kernels is set up a ZRAM paging device and set that to a high priority. ZRAM uses LZO compression on things destined for a swap file and keeps them in RAM; even with an SSD, LZO compressed in-ram swap is WAY faster unless your CPU is garbage. If the compressed swap is full, your normal swap file or partition will start to absorb the overflow, but by the time memory pressure is that high you can’t avoid swapping to the SSD anyway.

    This went into in /etc/rc for me; put it in a startup script for your distribution, might need to ‘modprobe zram’ first, and replace ‘3072’ with 1/2 to 3/4 of your total RAM; each 1024 = 1GB of RAM.

    # Set up ZRAM swap
    test -e /sys/block/zram0/disksize &&
    expr 3072 * 1048576 > /sys/block/zram0/disksize &&
    mkswap /dev/zram0 2>/dev/null >/dev/null &&
    swapon -p 100 /dev/zram0

  • John Spuzzum

    The .cache is in your /home directory… just put your /home on a standard sata drive while installing the os in the first place. You can do the same with the /tmp directory as well. Problem(s) solved.

  • Steffie

    I followed these steps in good faith [Linux Mint 17.1 64-bit KDE], & somehow i never noticed these important comments FIRST, & now exactly as forewarned in these comments, i have broken my Linux boot. Somehow now i need to edit fstab & grub back to their previous states [& maybe also move .cache back to its original place?], but as i cannot boot Linux it’s tricky for me [obviously i am not skilled with Linux “under the bonnet”, only knowing my way around it inside the GUI]. I am researching now trying to boot from a LiveCD to then somehow do it. I am disappointed in this page’s very bad advice, & unhappy with myself for being so naive.

  • adaptateur ac

    ♥ Ƹ̵̡Ӝ̵̨̄Ʒ..•*´¨`*•.¸♫.•*´¨(♥ˆ◡ˆ) ♥♥♥ (ˆ◡ˆ♥)¨`*•.¸♫.•*´¨`*•..Ƹ̵̡Ӝ̵̨̄Ʒ

  • watchingtheweasels

    So speaking as someone who broke his fstab following the directions in this article and ended up with an unbootable Linux system that would only go to thein single user manual recovery command line, here is how I fixed it.

    The problem is that single user command line recovery is read only so you have to remount your boot partition with both read and write permissions using this command if you actually want to edit fstab:

    mount -n -o remount -t extX /dev/hdaX /

    Where extX is your filesystem type and /dev/hdaX — is partition you use for your root mount point.

    In my case I had to just type “mount” with no parameters to find that I was booting off /dev/sdb1 and it was an ext4 partition. Your specifics may be different depending on how your system is configured, I have a two SSD drive desktop that dual boots Windows and Linux.

    So my command looked like this:

    mount -n -o remount -t ext4 /dev/sdb1 /

    After this I edited the fstab file with

    nano /etc/fstab

    and put relatime back in place of the incorrectly suggested noatimenodiratimediscarderrors=remount-ro

    It’s all working again.

  • Palloy

    You should, of course, back up /etc/fstab to /etc/fstab-old before messing with such a critical system file. Then if you make a mistake (as you will if you follow this article), and the boot fails, you can always reboot into a LiveCD and open a terminal:
    sudo cp /etc/fstab-old /etc/fstab
    and reboot into your old setup.

  • Palloy

    In Ubuntu 14.04 /var/spool/ contains /cron/crontabs/ which you will want to survive a reboot, so DON’T use the line:
    tmpfs /var/spool tmpfs defaultsnoatimemode=1777 0 0
    even with the commas:
    tmpfs /var/spool tmpfs defaults,noatime,mode=1777 0 0