Optimizing SSD

[semicolon]

Soon (hopefully) I will receive my new laptop with only a brand new large SSD, so no HDD any more. To have something to do while impatiently waiting on my new laptop to arrive, I decided to look around for things I need to know when my new laptop arrives. I came across the subject of optimizing the OS for a SSD. Curious as I am, I decided to read some more about the topic and found a lot of information about it, but unfortunately quite some advices are contradicting and others are already outdated.

I got the feeling many people still underestimate the power of new SSDs, but since I am no expert I hope you guys can help me out on some questions I still got after so much reading. If I state anything incorrectly below, please correct me.

Maximizing SSD Performance

• Enabling TRIM
Meant to avoid that the SSD slows down over time by a phenomenon called 'write amplification'.
enable by mount flags - recommended by https://wiki.archlinux.org/index.php/Solid_State_Drives#Apply_TRIM_via_cron
apply via cron - recommended by http://www.webupd8.org/2013/01/enable-trim-on-ssd-solid-state-drives.html

What are the pros and cons of enabling TRIM by mount flags and apply TRIM via a cron job?


• I/O Scheduler
Because on a SSD seek times are identical for all sectors, the I/O scheduler doesn't need to re-order or group I/O requests that are physically closer on the disk in the way this is usual for HDDs.

There seem to be two I/O schedulers to choose from, namely NOOP and Deadline. From what I understand the perfomance difference between these is small, the most important thing is not to use CFQ, am I right?


• Swap Space
A swap partition can be used by the OS when there is not enough internal memory, but with modern computers with more than 2GB of RAM this is rarely used.

Don't really understand how swap space could maximize the performance, but read that if the computer has enough memory it won't be used, unless you use hibernate. If I won't use hibernate, will I need it?

Minimizing Writes
SSD's have a limited number of write cycles and therefore minimizing the number of writes will add longevity to an SSD. (Often the reads are also mentioned, but these don't have an effect, or do they?)

Since SSD's have improved a lot over the last few years, I am actually doubting whether (some of) the following options are still worth the effort. After all, I chose an SSD to use it, not to avoid using it as much as possible. So please tell me which of the following is worthwhile.

• noatime Mount Flag
This eliminate the need by the system to make writes to the file system for files which are only being read.

If this can be disabled, why isn't it by default? It sure has a purpose, hasn't it?


• Mount browser temp files into RAM
It is possible to mount temporary files, for example of a browser, into RAM to reduce the number of writes to the SSD.

I understand this reduces the number of writes to the SSD drive and will therefore improve it's longevity, but won't it reduce the life expectancy of the RAM memory? And if so, how bad is that?

These aren't all options to optimize the system for the use of a SSD, but these reoccured on many websites. If you believe I missed a really important one, please say so.

As a final remark I would like to add that I think it would be better if linux Mint (and other linux distributions) would automatically detect a SSD and apply the appropriate settings for the user, this sure is possible, isn't it? Especially because SSDs become more and more apparent, I believe it would be well worth the effort of implementing it.

However, that's not my most important concern now. If anyone has an answer to any of the above questions I will love to hear them. Thanks!

[xenopeek]

Here are my SSD optimization steps: viewtopic.php?f=90&t=79503#p461796. I don't know the answers to all your questions though, and it seems there are pros and cons to the alternatives you ask about (at least its easy to get caught in conflicting advice and opinions when searching the Internet).

Enabling TRIM: Personally, I'm still using discard on my SSDs and it works fine. Perhaps when I install Linux Mint 15 I'll go the Web Upd8 recommended way of using cron.

I/O Scheduler: I'm using noop, but yes some say deadline. I don't want to waste my time doing a double-blind test to confirm it actually makes a difference

Swap Space: If you have enough memory to run your tasks, you don't need swap. It will slow you down on HDD and waste write cycles on SSD. If you want to hibernate (suspend to disk) then yes you still need swap, otherwise don't bother on a normal computer (4 GiB or more RAM).

noatime Mount Flag: it has some legacy use for some backup programs (not those that you are likely to use though), but otherwise all your software will work fine without it. It can be useful to be able to find files based on when you last accessed them. Though note that your desktop environment provides for a "recent used" files list, so that using noatime doesn't impact this.

Mount browser temp files into RAM: If RAM would fail that easily, stop playing 3D video games at once Those crunch more data per second in RAM than you are likely to use on /tmp per day.

[semicolon]

Thanks for your answers. To make things entirely clear...

noatime Mount Flag: it has some legacy use for some backup programs (not those that you are likely to use though), but otherwise all your software will work fine without it. It can be useful to be able to find files based on when you last accessed them. Though note that your desktop environment provides for a "recent used" files list, so that using noatime doesn't impact this.

Do you think it is worth the sacrifice? Modern SSDs have quite a long lifetime, the computer is probably already outdated before the (very little) extra lifetime would even start.

Mount browser temp files into RAM: If RAM would fail that easily, stop playing 3D video games at once Those crunch more data per second in RAM than you are likely to use on /tmp per day.

Yeah, actually quite obvious, but I can also ask here why isn't this done by default? Is it just because it occupies some of the available memory?

Also, do you think automatic application of appropriate settings when a SSD is detected will be implemented in future releases? Or do you know of any reason why it won't happen (soon)? I might just ask it in the development section of the forum.

[DrHu]

Yeah, actually quite obvious, but I can also ask here why isn't this done by default? Is it just because it occupies some of the available memory?

http://ubuntuguide.net/speed-up-firefox ... -in-ubuntu
--not exactly everything I meant, but partial data into RAM disk for the browser..

Perhaps because you need a setup for a ram disk, you need to create one and then set /tmp to use it
--for the most general setup, tweaks are not used: a RAM disk would be one such tweak

It is also a good way to prevent local browser data being stored, if you also redirect the specific browser storage file to the RAM drive

--not that it makes much difference, but in a company environment, I might want the least monitoring as possible, although they pretty much log everything on any company workstation: emails and so on, web sites visted, and times of course (I think they might believe it cuts into productivity (work production, whatever that may entail !)).

A RAM drive is also a good way to run a desktop, if you have plenty of RAM available, you can pretty much run the OS + applications from there and avoid any disk IO: it will be faster than any hard drive: ssd or otherwise
--pclinux is one distribution that makes use of this option
http://www.pclinuxos.com/?page_id=2

[xenopeek]

Do you think it is worth the sacrifice?

For my use, yes. I never use atime, nor having noatime is fine. I have a first generation Intel SSD so it may make more sense on that. I also have a newer SSD for OCZ, but I'm still using noatime there as I have no use for atime and it may extend lifespan of the SSD to a next computer...

why isn't this done by default?

Because some users or programs might put very large files in /tmp, larger than the available memory. Because not all users will have enough free memory (regardless of how much RAM they have) to do this with how they are using their computer. Because some select few specific programs might not work correctly with this (I can recall there was one old Linux game that didn't work right with it, but I can't recall the specifics). But I think there are some distros that now default to it, so perhaps this all doesn't weigh as heavily as it used to.

[catweazel]

I came across the subject of optimizing the OS for a SSD. Curious as I am, I decided to read some more about the topic and found a lot of information about it, but unfortunately quite some advices are contradicting and others are already outdated.

I run my SSDs in RAID0. 1.48GB/s throughput is not to be laughed at However RAID sets don't support TRIM.

Of the tips you've listed, the one about using cron and creating a short script to execute fstrim should be used. Do not put discard in fstab.

A few more things...

You can turn off ext4 journalling. If you want to use this tip you will have to turn it off before you install Mint. First create an ext4 partition in gparted then in a terminal:

Code: Select all

$ sudo mke2fs -t ext4 -O ^has_journal /dev/sda1
$ sudo tune2fs -o journal_data_writeback /dev/sda1
$ sudo tune2fs -m 1 /dev/sda1
$ sudo tune2fs /dev/sda1 -i 7d
$ sudo tune2fs /dev/md0 -c 15


The latter 3 commands reduce the reserved space to 1% of the drive, and turn on filesystem checking at once every 7 days or 15 boots, whichever comes first.

At install time, simply select the installer's 'Something else' option, choose the SSD as ext4 with root / as the mount point. Do not format the partition. After Mint is installed, you need to modify the fstab so that your root mount point looks like this:

Code: Select all

UUID=0002e9d5-5d5c-450e-82ca-9fdbd7b6c779  /   ext4    data=writeback,noatime 0       1

The UUID is an example only, above. Use the UUID of your SSD. It will be set in fstab during the install. Also note that data=writeback should only go into fstab if you've chosen to turn off journalling as described earlier.

Putting /tmp and /vsr/log into tmpfs is also good:

Code: Select all

tmpfs    /tmp     tmpfs   noatime,nodev,nosuid,noexec,mode=1777   0       0
tmpfs    /var/log tmpfs   defaults,noatime,mode=0755              0       0

Another good tip is to run profile-sync-daemon:

Code: Select all

$ sudo add-apt-repository ppa:graysky/utils
$ sudo apt-get update
$ sudo apt-get install profile-sync-daemon


You can get instructions here. The utility will put your browser's entire profile into tmpfs.

Regarding swap, you will need it if you intend to hibernate. I run without swap. The swap partition should be just a tad bigger than your RAM, up to about 1.5 times RAM maximum.

Cheers.

[xenopeek]

You can turn off ext4 journalling.

That's fine, but don't do that unless you completely understand what that does. No fault-resilience, no data-integrity. You drop those if you turn off journaling. Of course you still need to make regular backups of your important personal documents and such, because SSDs can also fail unexpected and unrecoverable. Anyway, my 10 bits.

[catweazel]

No fault-resilience, no data-integrity. You drop those if you turn off journaling.

Good point. I'll make sure I mention that in future.

Cheers.

[semicolon]

Thanks for your answers. I already read about journalling, but was so confused by it that I didn't even name it here, however I think it's good to mention in this thread.

Of the tips you've listed, the one about using cron and creating a short script to execute fstrim should be used. Do not put discard in fstab.

I heard more people say so, but also heard the people stating the opposite (e.g. on the archwiki). So could you please explain your statement?

[catweazel]

could you please explain your statement?

Yes, of course.

To put it bluntly, those who strongly advocate discard don't know what they're talking about

The discard option forces the SSD to 'FF' fill blocks while its doing normal I/O operstions. It won't long before there are noticable pauses in drive activity, which is nothing less than a severe performance hit. The discard option is not written to fstab by default for that very reason. That is, discard creates performance issues. Using the cron option with fstrim batches the job to once a day, usually about 15 minutes after startup. The batch job TRIMs the whole drive thus avoiding the performance hit while you're trying to get work done.

[eanfrid]

I use a fstrim cron job too. This is the way things should be done now. As for advice saying to use noop or deadline schedulers... this is probably outdated since cfq has been modified months ago to correctly handle SSD drives. On my Sandisk Extreme, I get better throughtput with cfq than with deadline and noop (in this order). Depending on your SSD it may be different, however. Regarding mount options, "noatime" and "nobarrier" are valuable fstab options, for either SSD or HDD but disabling journaling has very minor impact on perfs, at the price of big risks for your data.

[semicolon]

The discard option forces the SSD to 'FF' fill blocks while its doing normal I/O operstions. It won't long before there are noticable pauses in drive activity, which is nothing less than a severe performance hit.

Well thanks. Just because I really start to get into this I read some more about this and found on good old wikipedia that the shortcoming you are talking about is overcome in Serial ATA revision 3.1 which implements the Queud TRIM command. (http://en.wikipedia.org/wiki/TRIM#Shortcomings) So that would mean that if your SSD is compatible with Serial ATA revision 3.1 or later, you could use the discard flag without the performance penalty?

Not that it matters to me, because the documentation of my SSD states that it is compatible with Serial ATA revision 3.0.

I use a fstrim cron job too. This is the way things should be done now. As for advice saying to use noop or deadline schedulers... this is probably outdated since cfq has been modified months ago to correctly handle SSD drives. On my Sandisk Extreme, I get better throughtput with cfq than with deadline and noop (in this order). Depending on your SSD it may be different, however.

Thanks, it seems technology around SSDs changes so fast currently that it is almost impossible to keep up with it. And as always.. things only become more complicated when you know more about it.

[eanfrid]

I should add that "noatime", "nobarrier" and "data=writeback" mount options are the 3 major valuable speed/throughput tricks if you have an UPS or if you use a laptop.

[catweazel]

Regarding mount options, "noatime" and "nobarrier" are valuable fstab options, for either SSD or HDD

but disabling journaling has very minor impact on perfs, at the price of big risks for your data.

With the nobarrier option you've got a volatile write cache, which is also a risk to data. Lose power and it's by bye data, so I fail to see the big difference between nobarrier and turning off journalling.

The reason I turn off journalling is to reduce disk writes and lengthen the life of the SSD. It's not done for performance.

If it is genuinely a bad thing to turn off journalling then I will not recommend it, but I haven't seen any firm arguments against it.

[eanfrid]

Usually "nobarrier" is a risk only if you don't have an UPS and power fails. But IMO disabling journaling is a risk if you face any incident that may corrupt your data. This is why I prefer to use "data=writeback" rather than no journal at all.

[catweazel]

Usually "nobarrier" is a risk only if you don't have an UPS

I see you added your get-out clause as an afterthought

But IMO disabling journaling is a risk if you face any incident that may corrupt your data.

Such as?

I don't see that the level of risk is any higher whatsoever. I'm sorry but my view is that opinion doesn't cut it when technical matters are being discussed.

[nunol]

I turn off journalling on some partitions but not on my data partitions and not on my main OS partitions. I have data backups and I could restore the system with clonezilla but it's my personal preference to leave journalling on if I consider the partition important.

My secondary systems (and Virtual Machines) are almost all with ext4 and journalling off because they are not important and usually used to surf the web, testing and minor tasks. Last year the power failed many times but only had problems twice, both because of power failures while writing to the disk. One killed the OS after I tried to fix the file system, the other was easy to fix but I could have a data integrity issue and not know about it. There are some problems that no UPS can solve like system freezes due to bugs, etc.

I have systems without journalling that work without problems for many years, more than the typical OS life so it's not a problem for me for some usage scenarios but disabling journalling in ext4 is riskier than having journalling enabled in some situations.

[eanfrid]

But IMO disabling journaling is a risk if you face any incident that may corrupt your data.

Such as?

I don't see that the level of risk is any higher whatsoever. I'm sorry but my view is that opinion doesn't cut it when technical matters are being discussed.

The are many reasons for a machine to hang other than power failures: software freeze, memory freeze, kernel panic, overheating, CGU lock-up, for example and generally when you barely have a chance to sync data to disk before hitting the reset button (if Magic Sys-Req keys don't work and save the day).

[catweazel]

The are many reasons for a machine to hang other than power failures: software freeze, memory freeze, kernel panic, overheating, CGU lock-up, for example and generally when you barely have a chance to sync data to disk before hitting the reset button (if Magic Sys-Req keys don't work and save the day).

True, but then I'm an old (read ancient) Windwoes user so I keep lots of backups

Cheers.

[eanfrid]

Backups are mandatory but it is better not to have to restore them