Optimize Ubuntu (and other Linux) under SSD

Good day to all who read. In this mini article, I would like to collect and consider the main points of optimizing the work (and, of course, extending the life cycle) of solid-state drives. Almost all the information can be easily found on the net, but here I will try to mention a couple of pitfalls.

The first thing to start with is the choice of the file system. If the system is on the desktop - then there are no special questions - take ext4 journaling - which has a lot of advantages over the rest of the file system. Yes, there will be more recording cycles on the media, but there will be a guarantee that in the event of a power failure you will not lose data. On laptops, netbooks - there are batteries, and the likelihood of shutting down due to power loss is almost zero (but, of course, anything can happen), and therefore logging is usually recommended to be turned off. If you really want to do this, then after installing the system, we boot from the liveCD, and write in the terminal

tune2fs -O ^has_journal /dev/sda1
e2fsck -f /dev/sda1

Other methods are not recommended - lose TRIM support. Also, do not disable the log by adding the " writeback " parameter to the fstab configuration - the system will not start due to a mount error (if trim was previously enabled).

The next thing to consider is the paging file. Under my nickname (now - Ubuntu 11.04), the code is usually written, movies are watched in HD and the Internet is actively surfing. During this time, the swap file was never needed, the maximum consumption of RAM was 1GB, out of 2 available in the netbook.
If your scenario of using the system is similar to mine, or you do not have a desktop - the paging file is not needed. Otherwise, it is necessary to transfer it to the HDD. If the journaling can still be left, due to its relative harmlessness, then the swap section is definitely an evil, devouring both limited rewriting cycles and expensive gigabytes, the number of which modern SSD cannot boast of.
')
Well, the system is set - you can optimize! The very first step - the inclusion of TRIM - the main technology, which should extend the life and distribute the load SSD.
It is done very simply - open fstab (like this)

gksudo gedit /etc/fstab

looking for lines
"UUID = [NUMS-AND-LETTERS] / ext4 errors = remount-ro 0 1"
and replace with
"UUID = [NUMS-AND-LETTERS] / ext4 disard, errors = remount-ro 0 1"

Usually, trim is disabled by default, but I post a way to check - go under the root and execute commands

1. dd if=/dev/urandom of=tempfile count=10 bs=512k oflag=direct // write 5 MB of random data

2. hdparm --fibmap tempfile // Looking for any starting LBA address for the file

3. hdparm --read-sector [ADDRESS] /dev/sdX // Read data from the starting LBA file address, replace [ADDRESS] with your Starting LBA address from the output of the previous command

4. rm tempfile // Now delete the temporary file and synchronize the filesystem:
5. sync

Repeat point 3 - and look at the output of the console. If zeros appear, the trim works. If you fixed fstab, rebooted, but trim was not activated - look for errors in incorrect logging disable.

Further, it is worth remembering that our Nix loves to keep a variety of logs. And either transfer them to the HDD, or keep them in RAM until the system is rebooted. I believe that if your home is not a server, then the second option is optimal, and it is implemented by adding the following lines to fstab
tmpfs / tmp tmpfs defaults 0 0
tmpfs / var / tmp tmpfs defaults 0 0
tmpfs / var / lock tmpfs defaults 0 0
tmpfs / var / spool / postfix tmpfs defaults 0 0


By default, after each opening of the file - the system leaves the time of the last opening - unnecessary write operations. It's easy to wean - add to fstab before parameters
scard, errors = remount-ro 0
a couple more options -
relatime, nodiratime The first allows you to record only the change time (sometimes necessary for stable operation of some programs), the second - cancels the recording of access time to directories. In principle, instead of relatime, you can also put noatime , which will not update anything at all.

After this, it is worthwhile to set up a delayed write — the kernel will save the data waiting to be written to the disk and record it either when absolutely necessary or after a timeout. I set the timeout for 60 seconds, someone for 150.
To do this, open /etc/sysctl.conf and add the parameters
vm.laptop_mode = 5 // Enable mode
vm.dirty_writeback_centisecs = 6000 time in sc. Those. 100 units = 1 second

And finally, turn off the I / O scheduler, which was once needed to better position the HDD heads. To do this, go into the hornbeam config / etc / default / grub
and in line
GRUB_CMDLINE_LINUX_DEFAULT = “quiet splash” insert the parameter elevator = noop
Along the way, you can remove the unnecessary and uninformed splash screen, reducing the system startup time for a second, simply by removing the quiet splash .

Here, in general, the main points. Next is to show imagination - for example, move somewhere, or completely disable the browser cache and so on. As a reward for the done manipulations, your SSD will serve you faithfully and with every start will make you happy with a good speed.

Update
Many people note the need to align sections. Comrade isden thank you very much for the link to the topic. wiki.archlinux.org/index.php/SSD#Partition_Alignment
If you do not want to risk - then the magazine is better not to disconnect. Then trim will be guaranteed to work, and some data protection from major system failures.

Below - a few links on which received information.
vasilisc.com/ssd_ubuntu
tokarchuk.ru/2011/01/enable-trim-support-in-ubuntu
sites.google.com/site/linuxoptimization/home/ssd