Saturday, June 23, 2012

Setting up an SSD with Linux

Recently I bought an SSD to replace the deceased hard drive. It can be a straight reinstall, however if you want to get the most out of your SSD and ensure a long life it can pay to take a few extra steps.

SSDs are not like mechanical media in any way, shape or form. They are a very advanced Solid State device with complex firmware which aids it in extending its life as long as possible. What eventually can kil an SSD is writing to it. Every cell can only survive a certain number of write operations. They have technology to account for this by spreading out write operations and other such things, but a finite number is still finite.

Here is what I did. It may not be the best way to go but it is what I chose after much reading on the subject.

Partitioning


SSDs as I mentioned earlier have cells. Discrete blocks of memory. Depending on the manufacture these can be different sizes. What we want is to make sure that the data that is written to the SSD is aligned to these cells. If it isn't, it will be writing to more cells than necessary, causing a slight slow down, and of course wearing extra cells prematurely.

Honestly I'm struggling to come up with a decent analogy so I'll just say we want what the computer is reading and writing to line up with the cells. The easiest way is to align partitions to the MiB. No, not men in Black. MibiBytes. This can be done when setting up partitions in GParted. It has the option to align to MiB. Use that when partitioning for your nice new OS.

You should choose either Ext4 or even btrfs as they both support TRIM which is a special SSD specific thing for extending its life. This is a good thing.

Tweaks


Now that you are seeing me using your nice shiny install, these are the next steps I took.

Making the OS more drive friendly

I edited /etc/fstab to change the entries for my ext4 partitions.  Here's a simplified version of what I changed.

/dev/sda1 / ext4 rw,errors=remount ro,noatime,nodiratime,discard 0 0 
 
Don't worry about what partition it is. It's just a tweak of what was in my /etc/fstab. The important thing there is "noatime,nodiratime,discard"
What noatime does is stop the OS from updating the date stamp on a file every time it is accessed, which should be alright for a home system. If you want to keep an eye on file accesses you might want to omit it and nodiratime which as you may have guessed is the same but for directories.
"discard" is a funny beast which all you really need to know is that it is meant to play nice with TRIM, assuming your SSD supports it.

Save now if you want.  I hope you were making your changes as su or root, otherwise you've just wated a couple of minutes.

While we have /etc/fstab open, we might as well make a couple more changes if you have a good chunk of RAM to play with.

Putting temporary files in RAM


If you want to cut down on writes, you can shift your temporary files to RAM. Of course that can fill up your RAM if your system generates a lot of them. You can do this by using tmpfs.
The following added to /dev/fstab or edited if you already have separate partitions for any of these will put your temporary files in RAM.

tmpfs   /tmp       tmpfs   defaults,noatime,mode=1777   0  0
tmpfs   /var/log   tmpfs   defaults,noatime,mode=0755   0  0
tmpfs   /var/tmp   tmpfs   defaults,noatime,mode=1777   0  0
tmpfs   /var/spool tmpfs   defaults,noatime,mode=1777   0  0
  
You may not want to put /var/log in RAM. I didn't because i like my logs to persist after reboot. Which ones you add is a personal choice.

Changing drive scheduling

"What's that?" Well, it's how the operating system decides what gets priority when accessing a drive, and what order the data gets accessed in.

By default linux uses CFQ. Which is Completely Fair Queuing. The thing about this is it is more suited to rotating media as one of its features is ordering data to take advantage of where the hard drive platters are at a given point in time to increase throughput. We don't need this.

"deadline" is much more suited to an SSD.

the following lines were added to "/etc/rc.local" above "exit 0" on my system to make access to the SSD more suitable whilst maintaining CFQ to spinning media.

echo deadline > /sys/block/sda/queue/scheduler
echo 1 > /sys/block/sda/queue/iosched/fifo_batch
 
After this, depending on the specifics of your system you may need to do this.

sudo chmod +x /etc/rc.local

to make the script executable.

Other things to do

There are other steps you can take like reducing the swappiness of the swap partition if you have one. I have one but didn't bother because as yet the computer hasn't touched /swap.
You can also move or just symlink your browser cache to /tmp, or even create your own tmpfs mountpoint for it if you want. There are other optimisations too but the ones I outlined are the ones I chose to do.

I take no responsibility for broken hardware, corrupted software or lost data. All I did was tell what I did and why, and all this was after using my own brain and doing my own research so don't go crying to me if you blindly entered things into a text editor and your neigbours dog kennel burst into flames because you didn't know what forces you were meddling with.

References

Here are a few of the places I looked to for information. It's not complete but it is good reading. What is in these pages may not agree with what I did. I'm not saying that I'm right. I just chose to do things my way so YMMV.

Crunchbang linux article on optimising for SSD

Debian User Forum topic on SSD booting

APCMag article on SSD optimization

Good luck!