An SSD disk is not an ordinary disk. On an SSD disk, files are handled in a significantly different way, and if you just install your Linux distribution without taking these differences into consideration, you won't capture the benefits SSD can offer. In fact, you are likely to experience a serious performance decrease after you use the disk for a while.
Changing SSD cylinder defaults
Optimizing Linux for SSD begins before you start installing Linux on the disk. On your disk, partitions will be created and normally, these partitions are created on cylinder limits. By default, a cylinder consists of 16,065 512-byte sectors.
The problem is that SSD disks don't work too well if default cylinder sizes are used. Because for reading,
To avoid this problem, you should use fdisk to create partitions, with three options that specify the cylinder and head sizes to be used. You can do this by using the following fdisk command:
fdisk -H 32 -C 32 –c
This makes sure that the partitions are aligned in a way that is compatible to the SSD write and erase blocks.
Some modern distributions take care of this by default. Fedora Core 14, for example, makes the first partition automatically begin on sector 2048, which means that write and erase block are always in the same cylinder.
Setting up Ext4 for SSD
The next thing to take care of is the file system. Optimize the erase blocks on your file system by ensuring that files smaller than 512 KB are spread across different erase blocks. To do this you should make sure to specify the stripe width and stride to be used when you create your Ext4 file system. These values are specified in pages, which by default have a size of 4 KB. To create an optimal Ext4 file system, you should use:
mkfs.ext4 -E stride=128,stripe-width=128 /dev/sda1
If you want to modify parameters for an existing file system, you can use the tune2fs utility:
tune2fs -E stride=128,stripe-width=128 /dev/sda1
Setting i/o scheduler for SSD
The third part of the optimization, involves the i/o-scheduler. This is a kernel component that determines how I/O requests are being handled. The default value is Complete Fair Queueing, which is fine for normal hard driver, but not for SSD, which benefits from the deadline scheduler.
If you want to use the deadline scheduler for all hard disks in your system, you can include the line elevator=deadline to the line in GRUB where your kernel is loaded. If you only want it for one specific hard disk, you should include a line like the following to the rc.local file, so that it is applied for the specific hard disk every time that your computer boots. The following line for instance would do this for the /dev/sdb disk:
echo deadline > /sys/block/sda/queue/scheduler
Trimming the data blocks from SSD
The last important step is a trick is called “trimming,” which makes sure that when you remove a file, the data blocks actually do get wiped. Then empty blocks are available when you create new files. Without trimming, performance of your SSD will degrade as the data blocks get filled up. When using the discard mount option, data blocks will get cleared after deleting files, which is a huge performance benefit for your SSD. You need at least kernel 2.6.33 to have support for trimming.
To enable trimming, add the discard option to the lines that mount file systems on your SSD in /etc/fstab. The line that mounts the root logical volume for instance, and will look like this after enabling the trim option:
/dev/system/root / ext4 discard,errors=remount-ro,noatime 0 1
Noatime has also been added, which makes sure that the access times of files doesn't get updated every time a file is read, minimizing the amount of writes to your file system.
After making these modifications to the file systems in fstab, reboot your computer, or tell the file systems to re-read their options, using mount -o remount for each file system that you have in /etc/fstab.
ABOUT THE AUTHOR:Sander van Vugt is an author and independent technical trainer, specializing in Linux since 1994. He is also a technical consultant for high-availability (HA) clustering and performance optimization, as well as an expert on SLED 10 administration.
This was first published in April 2011