HOWTO - Optimize #! linux for use with a solid state drive (Page 1 of 2)

This is a guide I compiled from several other people's guides I found around the internet. Several suggestions other people made have been omitted, such as disabling file journaling, which I think is a ridiculous thing to do that can result in serious data loss. Even though I feel I have exercised my better judgement for the most part, follow this guide at your own risk!

Step 1: Formatting the drive with a GUID partition table
   Boot #! from a live cd or usb drive. Start up Gparted and go to Device-->Create New partition Table. Instead of using the traditional MS-DOS partition table, select GPT (GUID Partition Table). This will make Gparted automatically align your partitions on a 2048 sectors (or 1024KiB) block size base which should be compatible with the vast majority of SSD if not all. Create a single root partition that takes up the whole disk (more on this later). Before you apply these changes, right click the partition that you created and click on "Information." Make sure that the last sector is one less than a multiple of 2048. If it isn't, decrease the size of the disk accordingly until it is. For example, my 120gb drive has a first sector of 2048 and a last sector of 234440703, which is ((2048*114473)-1). Then just run the #! installer like you normally would (make sure to use ext4 as the file system type, install everything to the root partition you made, and ignore the messages about not having a swap partition (swap space not recommended for use on solid state disks for both performance and disk health reasons, and is not really necessary if you have at least 2Gb RAM, and if you don't, why are you spending money on a solid state disk!). GPT partition tables are not supported by GRUB legacy, but the #! disk I used installed GRUB2 by default, so if you are using an older version or a different distro, you might have to boot from a live environment again afterwards and run update-grub.
Alternative Method: If you would like to use LVM, or just have separate root and home partitions, I recommend using gdisk instead of gparted. This is a command line tool available in the squeeze repos. LVM uses a 192k header file which can offset your partitions and throw them out of alignment if you don't know what you're doing. It also has been known to cause bugs with TRIM, which we will install later in this guide. I do NOT recommend using LVM with a solid state drive until the kernel support for TRIM becomes better. There is more information on formatting a solid state disk using gdisk in the arch wiki: https://wiki.archlinux.org/index.php/Solid_State_Drives

Step 2: Upgrade to a 2.6.36 or newer kernel
   A newer kernel is necessary in order to enable TRIM. In case you're wondering, "what the hell is TRIM?" TRIM informs the NAND controller on your SSD when a block is no longer occupied. The fuller your SSD becomes, the more it's read/write performance degrades, and without TRIM, you will see this loss in performance even if you delete the files afterwards. Both the backported edition of statler and the waldorf beta ship with a kernel that supports TRIM. With #! statler stable, you will have to upgrade to a newer kernel to enable TRIM. For more information on installing testing packages see http://crunchbanglinux.org/forums/topic … edge-with/and/or http://www.debian.org/security/faq#testing

Step 3: Editing /etc/fstab
   In fstab we need to change 3 things, we need to enable TRIM support, disable writing access time to files, and mount the temporary file system and some log folders to the RAM. First you need to locate the entry in your fstab for your SSD, mine looked like this after the initial installation:

UUID=f4e8fefd-e4f1-4763-b7ab-a6fa291f0837 /               ext4    errors=remount-ro 0       1

We're going to change this to:

UUID=f4e8fefd-e4f1-4763-b7ab-a6fa291f0837 /               ext4    noatime,discard 0       1

The noatime option prevents your system from writing the last accessed time to a file every time it is read from. While not the best security practice on a server or system that is likely to be subject to unauthorized access, on your private laptop or desktop it can reduce a lot of unnecessary writes to the drive, increasing both the life of your drive and it's performance. The discard option enables the aforementioned TRIM. Remember that this fstab option will be in effect no matter which kernel you boot, so you might want to consider removing the menu entries for the stable kernel in your /boot/grub/grub.cfg. Enabling TRIM in a kernel older than 2.6.36 is highly inadvisable. Next we're going to change fstab some more so that certain folders are mounted in the RAM instead of on your SSD. Add the following to the end of your fstab (note: mounting /var/spool in the RAM will prevent anacron from starting, I don't particularly care if anacron runs on my laptop or not but you might want to omit this line if that bugs you):

tmpfs   /tmp       tmpfs   defaults,noatime,mode=1777   0  0
tmpfs   /var/log   tmpfs   defaults,noatime,mode=0755   0  0
tmpfs   /var/spool tmpfs   defaults,noatime,mode=1777   0  0
tmpfs   /var/tmp   tmpfs   defaults,noatime,mode=1777   0  0

Here is what my fstab looks like now:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
# / was on /dev/sda1 during installation
UUID=f4e8fefd-e4f1-4763-b7ab-a6fa291f0837 /               ext4    noatime,discard 0       1
/dev/scd0       /media/cdrom0   udf,iso9660 user,noauto     0       0

#temp file settings

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

Now save and exit your editor, and reboot your system. In the next step, we're going to do a couple things to verify that what we just did actually worked.

Step 4: Verifying Changes to fstab
   TRIM verification is the complicated part, so let's get that out of the way:

• Open a terminal and become root:

$sudo su

• Make a 50MB file with random data:

$dd if=/dev/urandom of=tempfile count=100 bs=512k oflag=direct

• Check the starting LBA address of the file:

$hdparm --fibmap tempfile

   Your output should look like this except the one number won't be in quotes:

 byte_offset  begin_LBA    end_LBA    sectors
           0    "580608"    582655       2048
     1048576     589824     591871       2048
     2097152     755712     767999      12288
     8388608     690176     722943      32768
    25165824   14338048   14354431      16384
    33554432   14780416   14796799      16384
    41943040   18761728   18778111      16384
    50331648   19105792   19109887       4096

• Read the first address of the file, note that you need to put the first LBA in place of [ADDRESS], this is the number that I put in quotes in the example but yours will be different:

$hdparm --read-sector [ADDRESS] /dev/sda

   This will spit out a bunch of hex code if you did it correctly.

• Now remove the file and synchronize the filesystem:

$rm tempfile
$sync

• Read the LBA again:

$hdparm --read-sector [ADDRESS] /dev/sda

If TRIM is properly working the result of the last command will be a bunch of zeros. If the output is NOT zeros, then something is wrong with your kernel/Ext4 configuration and TRIM is NOT working.

• Now verify that the temp file systems were mounted in RAM

$df

   The output should look something like this:

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1            115378728  11618480  97899284  11% /
tmpfs                  1537068         0   1537068   0% /lib/init/rw
udev                   1529084       228   1528856   1% /dev
tmpfs                  1537068         4   1537064   1% /dev/shm
tmpfs                  1537068        28   1537040   1% /tmp
tmpfs                  1537068       408   1536660   1% /var/log
tmpfs                  1537068         0   1537068   0% /var/tmp
tmpfs                  1537068         0   1537068   0% /var/spool

Step 5: I/O Scheduling optimization
   An I/O scheduler decides the order in which applications are given access to the SSD for writes and reads. In Linux, the default I/O scheduler in Linux is called CFQ, Completely Fair Queuing. CFQ generally works well, but it is not perfect for SSDs. Its default behavior is to give drive access on a first come - first serve basis. Sometimes overall system performance can be enhanced by using a different scheduling order. Also, there are schedulers which cause less wear on solid state drives. Two of the better I/O schedulers for SSDs are noop and deadline, and they are faster than CFQ when an application is writing large files.

To change the I/O scheduler of a disk to deadline until shutdown or reboot (This also allows you to set your scheduler on a per-drive basis so you can use BFQ or something else on additional storage devices that are traditional HDDs, for example):

$sudo echo deadline > /sys/block/sda/queue/scheduler && sudo echo 1 > /sys/block/sda/queue/iosched/fifo_batch

The drive's I/O default scheduler can be set automatically at boot time by entering the proper option into the boot loader. In my statler xfce system, line 82 of /etc/grub.d/10_linux was the one I needed to change, but this will vary from system to system, this is what it looked like before I changed it:

linux    ${rel_dirname}/${basename} root=${linux_root_device_thisversion} ro ${args}

This is what I changed it to in order to enable deadline as the default scheduler:

linux    ${rel_dirname}/${basename} root=${linux_root_device_thisversion} ro elevator=deadline ${args}

After editing the 10_linux file, issue (as root) the command "update-grub" rewrite the config file GRUB uses during boot time.
To check which scheduler is currently running, you can enter

$cat /sys/block/sda/queue/scheduler

Step 6: Moving Firefox's cache to RAM
   Moving the cache into RAM enhances the browser's speed and reduces writes to the SSD. Open Firefox, type about:config in the address bar, and press Enter. Promise to be careful! In an empty space on the screen, right-click and create a new string called:

value browser.cache.disk.parent_directory

Set the new string value to

/tmp

Edit: There is another thread that explains how to put chromium's cache in ram: http://crunchbanglinux.org/forums/topic … s-work-in/

And we're done! Palimpsest is a really neat graphical tool you can use to benchmark your SSD that is available in the debian repos, unfortunately it can only benchmark write speeds on an empty drive. Other great benchmarking tools you can use are bonnie++ ( available here: http://www.coker.com.au/bonnie++/) and iozone (available in the repos) which are terminal app that can be used on your drive after your system is installed and configured, you will have to compile it from the source though. You can also add the following to your .conkyrc to monitor the disk I/O in real time while you work:

Read: ${diskio_read sda} ${alignr}${diskiograph_read sda 8,70}
Write: ${diskio_write sda} ${alignr}${diskiograph_write sda 8,70}

Last edited by mynis01 (Yesterday 01:37:05)