Setting Mint up on an SSD

Write tutorials for Linux Mint here
More tutorials on https://github.com/orgs/linuxmint/discu ... /tutorials and (archive) on https://community.linuxmint.com/tutorial
Forum rules
Don't add support questions to tutorials; start your own topic in the appropriate sub-forum instead. Before you post read forum rules
Post Reply
marinu666

Setting Mint up on an SSD

Post by marinu666 »

There are many many websites out there with instructions on how to set yourself up on an SSD.

This guide will weight up the pros and cons of the points people raise about SSDs.
It will also show you how to setup linux on your SSD in a way which will (hopefully) maximise your life expectancy and help you to get the most out of your drive.

First one is write limits (relative to HDDs). This is not a myth, it is very much true! However, it is nowhere near as bad as it was when SSDs where first coming to age.

Step 1. Choose a File System
The first argument I have come across is ext2 v ext4 (journalled v.s. non-journalled).
SSDs have a feature called TRIM (or at least, new ones should support this!) For further reading than my explanation: http://en.wikipedia.org/wiki/TRIM. ext2 has very limited (if but any!) support for TRIM. It has to be done manually which is outside the scope of this article. ext4 has full automatic support for TRIM. So to make the most out of your SSD with regards to TRIM, ext4 is the way to go.

ext4 has a journal. This implements a kind of backup routine into the file system itself. If your drive is ever knocked off in the middle of a write, the data has a higher chance of being safe than in a non-journalled file system, such as ext2. In laptops, most of the time the drive wouldn't be turned off in this manner, as even in a power cut you have a built in UPS called a battery :P However, there are instances where you may run out of battery and the machine shuts off. So ext4 would be good to have just as a piece of mind!
It is all about stability and reliability against limiting writes. The journal uses so little writes that you may as well leave it on, just for that piece of mind!

What about ext3 you say?
ext3 is a journalled file system. But it is not as full featured as ext4. So it is generally dropped in favour of ext4.

Can I run ext4 for TRIM support, without a journal?
Yes you can. But, I would not recommend doing so. But if you insist on saving the writes caused by your journal here is how you would do it:

Code: Select all

tune2fs -O ^has_journal /dev/sdxY
where x is your disk letter, and Y is your partition number. (<-- if you do not have enough experience to know what this means, or what letters/numbers map to your drive, then I suggest you leave your journal on!)


Step 2. Installation (skip to step 3 if you already have a working system :) )
Now install your Linux to your SSD, using whatever method you normally do (USB Boot, CD ROM etc etc)

Step 3. Set up the File System
I will only cover ext2 and ext4, as ext3 should be avoided. If you choose to use ext3, please adapt this to your whims! :)
EXT4:
Most modern SSDs use the TRIM option mentioned above. We can enable this using a mount option called "discard".
We also want to limit writes as much as possible! So we are going to disable the two "atimes" that the filesystem is normally mounted with. The noatime option specifies "do not write any access times to files, and the nodiratime specifies "do not write any access times to directories". Having both these off means your SSD will not write when you merely READ a file. (Some people argue that noatime implies nodiratime, but I always use both - I am unsure if this is the case, so better safe than sorry! :) )

Take administrative priv's (su) or use sudo and run the command:

Code: Select all

nano /etc/fstab
For basic installs you will see a line underneath a comment that says "# / was on /dev/sdxY during installation". For basic instructions I will assume you have one partition on your SSD and that it is on sda1.
You want to change the line underneath, and find the section that says errors=remount-ro. Just before it put the mount options "noatime,nodiratime,discard". So that your line looks similar to mine:

Code: Select all

UUID=e6b4be1b-01ab-4bcf-b880-234c593798ad /               ext4    defaults,noatime,nodiratime,discard,errors=remount-ro 0       1
NB: If your SSD does not support TRIM, then leave off the discard flag. If you are using an old kernel (I believe 2.6.something is earliest for TRIM in the kernel - also leave out the discard flag).

EXT2:
Edit your fstab with administrative privs

Code: Select all

nano /etc/fstab
As ext2 does not support trim, we cannot use discard - except in read-only mode. Which is useless for user files so just mount with the option "noatime" and "nodiratime" (see above in the ext4 section for what they do)

You want to change the line underneath, and find the section that says errors=remount-ro. Just before it put the mount options "noatime,nodiratime". So that your line looks similar to mine:

Code: Select all

UUID=e6b4be1b-01ab-4bcf-b880-234c593798ad /               ext2    defaults,noatime,nodiratime,errors=remount-ro 0       1

Step 4. SSD Disk Scheduler
There are several disk scheduling systems for you to choose from in the kernel.

CFQ - Completely Fair Queueing
CFQ places synchronous requests submitted by processes into a number of per-process queues and then allocates timeslices for each of the queues to access the disk..... (Further Reading http://en.wikipedia.org/wiki/CFQ)

NOOP - Noop Scheduler
The NOOP scheduler inserts all incoming I/O requests into a simple FIFO queue and implements request merging. (Further Reading: http://en.wikipedia.org/wiki/Noop_scheduler)

Deadline - Deadline Scheduler
This is similar to NOOP, except it has prioritisation for reads over writes, so that the disk remains responsive under heavy write conditions. (Further Reading: http://en.wikipedia.org/wiki/Deadline_scheduler)

NOOP and Deadline are the two of choice for SSDs, CFQ is optimised for spinning platter disks. I personally have chosen deadline so that my disk remains responsive if I have VirtualBox or a Compilation Operation active doing heavy writes.

To find out the scheduler in use you can run the following command (assuming sda is your SSD):

Code: Select all

cat /sys/block/sda/queue/scheduler
Giving something similar to:

Code: Select all

root@darksibling-006:/home/anthony $ cat /sys/block/sda/queue/scheduler
noop [deadline] cfq 
To change your scheduler to deadline for this session run (with admin privs, su or sudo):

Code: Select all

cat deadline > /sys/block/sda/queue/scheduler
To change it for all sessions, you need to instruct grub to tell the kernel it should be using deadline
with admin privs, run:

Code: Select all

nano /etc/default/grub
About 10 lines down you will see the variable GRUB_CMDLINE_LINUX_DEFAULT
It will have some items in it, such as quiet and/or splash.

Change it so that it looks like this:

Code: Select all

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash elevator=deadline"
Now update grub (as admin user)

Code: Select all

update-grub
Now next time you restart your machine - you should be using the deadline scheduling system. Hopefully giving a speed boost as a result.


Step 5. Further Reducing Writes
Personally, I believe that SSDs are much more resilient than people give them credit for. I remember reading somewhere that somebody had made an SSD fail but they had written hundreds of gigs an hour to it. I also remember reading that an SSD can be expected to last 5+ years if you write an average of 20GB a day to it (i believe this was on a 32GB SSD).

However, if you want to further reduce writes you can add the following to your /etc/fstab providing you have enough Physical Memory to handle it. All information in these mounts WILL BE LOST on reboot.

Code: Select all

tmpfs       /tmp        tmpfs       defaults,mode=1777      0   0
tmpfs       /var/tmp    tmpfs       defaults,mode=1777      0   0
tmpfs       /var/spool  tmpfs       defaults,mode=1777      0   0
tmpfs       /var/cache  tmpfs       defaults                0   0
* - If defaults gives you too small of a partition, for example in /tmp. You can change it by using the size=XM where X is the size in MB
such as: tmpfs /var/tmp tmpfs defaults,size=1024M,mode=1777 0 0

You can also add:

Code: Select all

tmpfs       /var/log    tmpfs       defaults,mode=0755      0   0
But I would advise against it. This is because you would have to write a script to re-create the folder structure inside /var/log on boot. As the structure is lost, when you reboot it can stop things working.
Here is an example to show you what I mean

Code: Select all

root@darksibling-006:/var/log $ /etc/init.d/apache2 start
 * Starting web server apache2                                                                                                                                         apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1 for ServerName
(2)No such file or directory: apache2: could not open error log file /var/log/apache2/error.log.
Unable to open logs
Action 'start' failed.
The Apache error log may have more information.
                                                                                                                                                                [fail]
As you can see apache refused to boot as "could not open error log file /var/log/apache2/error.log.".

Step 5b. Further Reducing Writes
The final thing you can do that I can think of. BUT ONLY IF YOU HAVE ENOUGH RAM.
Is to symlink your .cache directory, from ~/.cache to /tmp/[youruser]/.cache
remember you will have to rebuild this directory structure in tmp each time you boot, and if you share the machine I would suggest chmod to 0700 in tmp!

By symlinking .cache over to memory. Several programs instantly have their heavy write files/folders dumped in RAM and do not hit your shiny new SSD. Google Chrome is an example of a program that uses ~/.cache

I think this should work for you if you put it in your .profile or your .bashrc (nano ~/.profile):

Code: Select all

iam=`whoami`
mkdir -p /tmp/${iam}
ln -sf /tmp/${iam} /home/${iam}/.cache
chmod 0700 /tmp/${iam}
With regard to Firefox, you could use the following to have Firefox put the cache into /tmp which is setup to use RAM in the fstab file:
Inside Firefox, type about:config in the address line. Then right click to add the following new string:
value browser.cache.disk.parent_directory
Set the string value to: /tmp
Thanks to powerhouse for the firefox instructions :)

Step 6. Swap
If you have limited physical memory, and you only have an SSD in your system. Then unfortunately you may have to use swap.
The linux kernel is very very efficient at handling swap and will only use it when you are literally OUT of memory. In contrast to windows which uses it as standard even when there is generally not even a need to do so. My friend goes through about one SSD per 6-9 months on windows.

If you have limited physcial memory, and a HDD and SSD in your system. I would suggest you put the swap on the HDD.

If you have a lot of physical memory, then you may choose to have a SWAP partition if you want. As you may never even reach it.


Thanks for reading!
Please feel free to comment, If you have any ideas or things to add please let me know. I am happy to edit my post and credit you in where additions are made :) And if I have made any mistakes or described something wrong please also let me know!
Last edited by marinu666 on Sat Sep 15, 2012 3:41 am, edited 1 time in total.
powerhouse
Level 6
Level 6
Posts: 1144
Joined: Thu May 03, 2012 3:54 am
Location: Israel
Contact:

Re: Setting Mint up on an SSD

Post by powerhouse »

Excellent tutorial - thanks for posting.

With regard to Firefox, you could use the following to have Firefox put the cache into /tmp which is setup to use RAM in the fstab file:

Inside Firefox, type about:config in the address line. Then right click to add the following new string:

value browser.cache.disk.parent_directory

Set the string value to: /tmp

Cheers!
Subjects of interest: Linux, vfio passthrough virtualization, photography
See my blog on virtualization, including tutorials: https://www.heiko-sieger.info/category/ ... alization/
wesolek

Re: Setting Mint up on an SSD

Post by wesolek »

Very good tutorial!

There are two corrections from me:

1. For the user-cache it should be like this to work

Code: Select all

iam=`whoami`
mkdir -p /tmp/${iam}
rm -r /home/${iam}/.cache
ln -sf /tmp/${iam} /home/${iam}/.cache
chmod 0700 /tmp/${iam}
2. loading /var/cache in ram will give you problems while installations, so I would suggest to comment it or to delete the line

Code: Select all

#tmpfs       /var/cache  tmpfs       defaults                0   0
greetings
piotr
marinu666

Re: Setting Mint up on an SSD

Post by marinu666 »

wesolek wrote:Very good tutorial!

There are two corrections from me:

1. For the user-cache it should be like this to work

Code: Select all

iam=`whoami`
mkdir -p /tmp/${iam}
rm -r /home/${iam}/.cache
ln -sf /tmp/${iam} /home/${iam}/.cache
chmod 0700 /tmp/${iam}
2. loading /var/cache in ram will give you problems while installations, so I would suggest to comment it or to delete the line

Code: Select all

#tmpfs       /var/cache  tmpfs       defaults                0   0
greetings
piotr

If you put the remove in your profile as you suggest, everytime that your bashrc/profile etc is loaded, you will remove the .cache folder. If you are in the middle of using (say) google-chrome, and you open a terminal - this will cause the terminal you just opened to delete your cache folder and hence everything that your google chrome is currently in the process of using - this applies to any program that would be putting data in .cache. This is not a good idea - it may cause programs to perform wierdly as they expect certain files to still be there etc. I did this originally and I got pages loading data from cache that wasn't there - and I would just get white "pictures" where the cached images were supposed to be.

On an unrelated note, rm -r can often fail if it hits certain folders. so I would suggest the command

Code: Select all

yes | rm -r [FOLDER]


I have not had any issues with /var/cache being in RAM - can you give more information about what might happen :) and I will remove it from the suggested setup if the problem is reproducible etc :)
powerhouse
Level 6
Level 6
Posts: 1144
Joined: Thu May 03, 2012 3:54 am
Location: Israel
Contact:

Re: Setting Mint up on an SSD

Post by powerhouse »

marinu666 wrote:...We also want to limit writes as much as possible! So we are going to disable the two "atimes" that the filesystem is normally mounted with. The noatime option specifies "do not write any access times to files, and the nodiratime specifies "do not write any access times to directories". Having both these off means your SSD will not write when you merely READ a file. (Some people argue that noatime implies nodiratime, but I always use both - I am unsure if this is the case, so better safe than sorry! :) )...
I only used noatime so far, but I agree with you - better safe than sorry (I just added nodiratime in my fstab).

Here is an easy way to check if noatime also works on directories:
1. Open a termin window and type:

Code: Select all

cd /boot
ls -lt -u
Note the date and time for the "grub" entry.
2. Open Caja, Nautilus or whatever file browser you use and navigate to /boot/grub, then back to / (root).
3. Enter again:

Code: Select all

ls -lt -u

If you booted and mounted your /boot or / directory with "noatime" in your /etc/fstab file, you should see that the date/time entry for "grub" hasn't changed. Here is how it looks on my PC:
  • user@linux /boot $ ls -lt -u
    total 71431
    drwxr-xr-x 3 root root 5120 Dec 15 12:05 grub
    -rw-r--r-- 1 root root 791023 Dec 15 11:30 abi-3.2.0-23-generic
    -rw-r--r-- 1 root root 791446 Dec 15 11:30 abi-3.2.0-30-generic
    -rw-r--r-- 1 root root 791446 Dec 15 11:30 abi-3.2.0-31-generic
    -rw-r--r-- 1 root root 15067588 Dec 15 11:30 initrd.img-3.2.0-23-generic
    -rw-r--r-- 1 root root 15158860 Dec 15 11:30 initrd.img-3.2.0-30-generic
    drwxr-xr-x 2 root root 12288 Dec 15 11:30 lost+found
    -rw-r--r-- 1 root root 4965840 Dec 15 11:30 vmlinuz-3.2.0-23-generic
    -rw-r--r-- 1 root root 140279 Dec 15 05:15 config-3.2.0-23-generic
    -rw-r--r-- 1 root root 140432 Dec 15 05:15 config-3.2.0-30-generic
    -rw-r--r-- 1 root root 140459 Dec 15 05:15 config-3.2.0-31-generic
    -rw-r--r-- 1 root root 731592 Dec 15 05:15 xen-4.1-amd64.gz
    -rw-r--r-- 1 root root 15167005 Dec 15 04:24 initrd.img-3.2.0-31-generic
    -rw-r--r-- 1 root root 178944 Dec 8 22:44 memtest86+_multiboot.bin
    -rw------- 1 root root 2883362 Dec 8 22:44 System.map-3.2.0-30-generic
    -rw------- 1 root root 2883401 Dec 8 22:44 System.map-3.2.0-31-generic
    -rw------- 1 root root 4963280 Dec 8 22:44 vmlinuz-3.2.0-30-generic
    -rw------- 1 root root 4963792 Dec 8 22:44 vmlinuz-3.2.0-31-generic
    -rw-r--r-- 1 root root 176764 Dec 8 22:44 memtest86+.bin
    -rw------- 1 root root 2884358 Dec 8 22:44 System.map-3.2.0-23-generic
    user@linux /boot $

As you can see from the date/time of this post and the directory listing above, I had forgotten to add the noatime option to my /boot partition entry (an ext2 partition) in /etc/fstab which is why "drwxr-xr-x 3 root root 5120 Dec 15 12:05 grub" carries today's date. I'm glad I reread this howto and checked my fstab :D .

The above method works for all folders, and of course you can also open a file and see if the access time changes.
Subjects of interest: Linux, vfio passthrough virtualization, photography
See my blog on virtualization, including tutorials: https://www.heiko-sieger.info/category/ ... alization/
powerhouse
Level 6
Level 6
Posts: 1144
Joined: Thu May 03, 2012 3:54 am
Location: Israel
Contact:

Re: Setting Mint up on an SSD

Post by powerhouse »

Here is my perhaps most valuable advice on this topic:

Leave plenty of spare disk space on your SSD and don't fill it up!

You may say "Why shouldn't I, I've paid $$$ and I want to use the most of my fast and expensive SSD space".

With spare disk space I mean total free (unused) SSD disk space. If you run a dual-boot setup with several Linux and Windows partitions, the SSD doesn't care if Linux is cramped and Windows has spare space on its partitions, as long as there is spare space.

Here is a simplified rule: If you, say, have a 120GB SSD and leave 60GB empty, you approximately doubled the number of possible writes per (utilized) storage unit = in other words, you doubled the lifetime of your SSD.

SSDs don't like to be filled up to the max - this can severely reduce SSD lifetime. The above example is a bit extreme, but implementing the advice of marinu666 above AND leaving around 20-30% of the SSD empty will help you enjoy the SSD for a long time.
At the same time, BACKUP is more important than ever with SSDs!

For more explanations on why to leave space on SSDs, see here http://www.overclock.net/t/1296817/linu ... t_17986671 and my answers here http://www.overclock.net/t/1296817/linu ... t_17993940 and here http://www.overclock.net/t/1296817/linu ... t_18003367.

For even more (and better) explanations, see here http://arstechnica.com/information-tech ... ly-work/3/.

P.S.: Don't run disk benchmarking tools on your SSD. You could as well use a sledge hammer on it to see how solid it is.
Subjects of interest: Linux, vfio passthrough virtualization, photography
See my blog on virtualization, including tutorials: https://www.heiko-sieger.info/category/ ... alization/
ryiden

Re: Setting Mint up on an SSD

Post by ryiden »

Mapping /var/cache to a temporary filesystem crashed apt.

Code: Select all

#tmpfs       /var/cache  tmpfs       defaults                0   0
Because apt stores the installed packages in /var/cache/apt/archive, all installed packages will be lost on reboot.
In my case "apt-get upgrade" failed because a new package had a dependency to an already installed one. But the already installed package cannot be resolved anymore, because it has been installed some reboots before.

Now im trying to download and reinstall all packages over synaptic. I hope, the package cache will be build up correctly.
ryiden

Re: Setting Mint up on an SSD

Post by ryiden »

I have improved the
.bashrc
script a little bit. My version supports the "sudo -s" command with /root as home folder. And the symbolic link wil be created only if necessary.

Code: Select all

IAM=`whoami`

# Also works for root's home: "/root/.cache",
# e.g. if you are using the "sudo -s" command
CACHE_PATH="/home/$IAM/.cache"
if [ "root" == "$IAM" ]; then
    CACHE_PATH="/root/.cache"
fi

# Create the target cache in "/tmp"
TARGET_PATH="/tmp/$IAM/cache"
mkdir -p $TARGET_PATH

# Link the user cache to "/tmp",
# but only if a symbolic link does not exist.
if [ ! -L $CACHE_PATH ]; then

    # Remove existing directory
    echo "Removing cache directory: $CACHE_PATH"
    rm -rf $CACHE_PATH

    # Link the user cache to "/tmp"
    echo "Creating symbolic link: $CACHE_PATH -> $TARGET_PATH"
    ln -sf $TARGET_PATH $CACHE_PATH
    chmod 0700 $TARGET_PATH

fi
eanfrid

Re: Setting Mint up on an SSD

Post by eanfrid »

Code: Select all

tmpfs       /var/spool  tmpfs       defaults,mode=1777      0   0
will wipe any non-system cron tasks on reboot too... not a very good idea either.

Other remarks:
- the "nodiratime" mount option is a subset of "noatime" => "noatime" is enough.
- managing trim with the "discard" option is not recommended: you should use regularly "(sudo) fstrim <mountpoint>" instead (once a day e.g.) for each partition.
- for ext2 mountpoints, the "hdparm" package contains an offline (previously unmounted partition) trimming script called "wiper.sh".
Post Reply

Return to “Tutorials”