Setting Mint up on an SSD
Posted: Fri Sep 14, 2012 2:49 am
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 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:
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:
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:
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
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:
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):
Giving something similar to:
To change your scheduler to deadline for this session run (with admin privs, su or sudo):
To change it for all sessions, you need to instruct grub to tell the kernel it should be using deadline
with admin privs, run:
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:
Now update grub (as admin user)
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.
* - 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:
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
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):
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!
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 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
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
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
EXT2:
Edit your fstab with administrative privs
Code: Select all
nano /etc/fstab
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
Code: Select all
root@darksibling-006:/home/anthony $ cat /sys/block/sda/queue/scheduler
noop [deadline] cfq
Code: Select all
cat deadline > /sys/block/sda/queue/scheduler
with admin privs, run:
Code: Select all
nano /etc/default/grub
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"
Code: Select all
update-grub
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
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
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]
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}
Thanks to powerhouse for the firefox instructionsWith 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
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!