CrunchBang Linux

mynis01

#! Die Hard

From: 127.0.0.1

Registered: 2010-07-02

Posts: 1,718

HOWTO - Optimize #! statler for use with a solid state drive

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 (2012-10-24 23:48:10)

rabbitofdeath

#! Member

From: Texas

Registered: 2010-11-10

Posts: 83

Website

Re: HOWTO - Optimize #! statler for use with a solid state drive

Thank you! I just got an ssd for my laptop and while its blazing fast - you can't have too much speed. I'll report back with results

bobrossw

#! Die Hard

Registered: 2011-02-08

Posts: 521

Re: HOWTO - Optimize #! statler for use with a solid state drive

I set up my own new SSD a little while ago, and started following guides like this one.  At some point I came across some stuff that said effectively that modern SSD drives don't have the same limitations as early ones, which could burn out in a week if not configured properly and that most modern SSDs should last somewhere on the order of 50 years even with the most grueling of usage.  I'm not an expert by any means, so I'd like to hear from anyone here that knows better.  Can anyone confirm or deny this?

mynis01

#! Die Hard

From: 127.0.0.1

Registered: 2010-07-02

Posts: 1,718

Re: HOWTO - Optimize #! statler for use with a solid state drive

I'm definitely no expert either, but you would be correct that the life of a drive is not nearly as big a concern now. You could just install #! on an SSD just like you do a normal drive, and it will most likely last you 10+ years. The guide is meant more as a means to increase read/write performance, and the more you reduce unnecessary reads/writes the faster the ones you depend on will be.

bobrossw

#! Die Hard

Registered: 2011-02-08

Posts: 521

Re: HOWTO - Optimize #! statler for use with a solid state drive

glad to hear it...I did some optimizations but not all.  Just wanted to make sure people know that they don't have to worry about doing it wrong.  It's easy to think that since you see conflicting things on-line (since old stuff tends to stick around a while).

lewk

Member

Registered: 2011-04-12

Posts: 12

Re: HOWTO - Optimize #! statler for use with a solid state drive

here is a link: http://en.wikipedia.org/wiki/SandForce for what should be considered before busing an SSD, not all are created equally of course. as much as your pockets will allow, entertain and act on symmetry of read/write speeds. cheap drives fail woefully in this area and i would not purchase one with someone else's money.

AlanD

#! CrunchBanger

Registered: 2011-05-12

Posts: 116

Re: HOWTO - Optimize #! statler for use with a solid state drive

Thanks! I guess I am installing again.

Maybe what I will do is:
1:liveCD
2:copy install to external drive
3:create new partition table
4:copy back data
5:fix up fstab

my home is on a separate 7200 rpm sata2.

cwgtex

New Member

Registered: 2011-05-20

Posts: 6

Re: HOWTO - Optimize #! statler for use with a solid state drive

Thanks for the pointers mynis01.  Up until tonight, I had only been testing out crunchbang in virtual machines.  I finally got around to installing it for real.  I wiped my whole disk and now I'm up and running very nicely.

n1v3k

New Member

From: Venezuela

Registered: 2011-05-22

Posts: 8

Website

Re: HOWTO - Optimize #! statler for use with a solid state drive

Awesome!

I read years ago that the <eeepc 4g> should use ext2 with the parameter "noatime" and no swap partition. so I remove my ext3 partition and swap. and create one ext2 partition with noatime

The EEEPC 4G has a solid state drive. and after 3 years mine still goes =P

pvsage

Internal Affairs

From: North Carolina

Registered: 2009-10-18

Posts: 9,033

Re: HOWTO - Optimize #! statler for use with a solid state drive

ext4 is running just fine on the SSD on my Dell Mini 9...noatime, relatime, no swap...I've heard that journaling does cause "disk" space usage to slowly inflate though, but I like having the "belt & braces" sense of security that journaling provides.

---

while ( ! ( succeed = try() ) );
We've earned a reputation as a nice, friendly community; please help us keep it that way.

snowpine

#!-a-roo

Registered: 2008-11-24

Posts: 2,555

Re: HOWTO - Optimize #! statler for use with a solid state drive

No problems with ext4 on my Dell Mini 9 with 8gb SSD. (No swap.)

I experimented with ext2 a couple of years back, and the problem is you can lose data if the battery runs down.

---

/hugged

mynis01

#! Die Hard

From: 127.0.0.1

Registered: 2010-07-02

Posts: 1,718

Re: HOWTO - Optimize #! statler for use with a solid state drive

Only ext4 and brfs have trim support. While disabling journaling can increase i/o speed in some situations, I highly recommend that you do not disable it, unless you just don't care about losing the data on the drive. I posted a benchmark of my drive here with journaling/trim enabled using the 2.6.38bpo kernel, I'm pretty satisfied with the results! Feel free to post your guys benchmarks in there, I'm curious!

albacore

Member

Registered: 2011-05-22

Posts: 12

Re: HOWTO - Optimize #! statler for use with a solid state drive

I had formatted to ext2 on the eeePC I was writing my thesis, I wasn't amused when I lost a day of work to a kernel panic...

Milozzy

#! Die Hard

Registered: 2011-02-22

Posts: 587

Website

Re: HOWTO - Optimize #! statler for use with a solid state drive

Thank you for this very interesting post!
On my eeepc I need more than one partion, in fact I can renounce to a separate /home but I need to keep a small EFI partition for the boot booster function (that saves me 5-10 sec at start up).
I read your guide but I have not understand if creating more than one partition with a GUID partition table is a difficult operation or not...

GuruX

#! Die Hard

Registered: 2009-01-18

Posts: 527

Re: HOWTO - Optimize #! statler for use with a solid state drive

I set up my own new SSD a little while ago, and started following guides like this one.  At some point I came across some stuff that said effectively that modern SSD drives don't have the same limitations as early ones, which could burn out in a week if not configured properly and that most modern SSDs should last somewhere on the order of 50 years even with the most grueling of usage.  I'm not an expert by any means, so I'd like to hear from anyone here that knows better.  Can anyone confirm or deny this?

A modern SSD won't wear out in a week. I believe that all of the modern SSD implements wear levelling in the SSD controller. In other words makes sure that the cells of ones and zeros gets written an equal amount of times. Not just rewriting the first available cell each time.
TRIM is another story. That's about making sure that you have blocks (512k pieces of the SSD) fully empty before writing data. A MLC SSD (the ones we usually use, SLC are expensive!) can only write full blocks due to hardware limitations.
A MLC SSD is built like cells -> pages (4K) -> blocks (512k).

I'd recommend the SSD Anthology from Anandtech if anyone is deeply interested of the SSD hardware structure.

schlem

#! CrunchBanger

From: Ballard, USA

Registered: 2011-03-20

Posts: 118

Website

Re: HOWTO - Optimize #! statler for use with a solid state drive

NOW you tell me. 
(Upgrading to 205GB mechanical disk in the near future anyway.)

---

这个空间特意留空

cwgtex

New Member

Registered: 2011-05-20

Posts: 6

Re: HOWTO - Optimize #! statler for use with a solid state drive

This howto was very useful, thank you!  I vote it gets stickied.

At first I wasn't getting the zeros in step 4.  After some research I found that my SSD (a Corsair P128) didn't get TRIM enabled until the most recent firmware.  After I got that updated, everything worked great!

tonyoptical

#! CrunchBanger

Registered: 2009-09-08

Posts: 198

Re: HOWTO - Optimize #! statler for use with a solid state drive

Hi

My new SSD Corsair C300 - 128GB has just arrived ...
May you help me with the maths calculating the correct partition size?
The last sector is 250068991. As per step 1 of your howto i should set it to 250068990 ...
How to do that in gparted?
Thx.

mynis01

#! Die Hard

From: 127.0.0.1

Registered: 2010-07-02

Posts: 1,718

Re: HOWTO - Optimize #! statler for use with a solid state drive

Actually according to my math your last sector should be 250066943, which is ((122103*2048)-1). In gparted iirc (it's been a while since I wrote the guide) you just have to guess and check with the partition size until you get it right, you can right click the partition and click information to view the starting and ending sectors before you actually write the changes to the partition table. Alternatively, there is a command line tool gdisk that you can use from a command line that allows you to directly specify starting and ending sectors.

tonyoptical

#! CrunchBanger

Registered: 2009-09-08

Posts: 198

Re: HOWTO - Optimize #! statler for use with a solid state drive

@mynis01

Thx. a lot. Installation completed - except step 5.

Changing the line 82 of /etc/grub.d/10_linux somehow failed on my testing system (didn't boot afterwards) and i didn't dare to apply that again on the productive system (openbox-amd64-liquorix). And i need to figure out how to move Opera's cache to the RAM cause i don't use firefox.

tonyoptical

#! CrunchBanger

Registered: 2009-09-08

Posts: 198

Re: HOWTO - Optimize #! statler for use with a solid state drive

Amendment to Step 6 - Move Opera's cache to /tmp/ by doing this:

opera:config#UserPrefs|OperatorCacheDirectory4

mynis01

#! Die Hard

From: 127.0.0.1

Registered: 2010-07-02

Posts: 1,718

Re: HOWTO - Optimize #! statler for use with a solid state drive

Are you sure you changed the correct line tony? Like I pointed out, which line it appears on varies from system to system. Did you test the scheduler out before you altered /etc/grub.d/10_linux? And did you try using noop or just deadline? And as far as that optimization for opera that you posted, you just type that into the url bar? I don't use Opera so I can't test it out. Also if someone knows how to make the same type of modification to chrome that would make a great addition to the guide since it is the default browser.

pghjake

#! Member

From: Pittsburgh, PA, USA

Registered: 2009-02-07

Posts: 78

Re: HOWTO - Optimize #! statler for use with a solid state drive

For Chromium, you need to update /etc/chromium-browser/default as root.

Add something like this
CHROMIUM_FLAGS="--disk-cache-dir="/tmp/ram/""

Note the quotes enclosing the flag text and the quotes enclosing the temp dir location.

tonyoptical

#! CrunchBanger

Registered: 2009-09-08

Posts: 198

Re: HOWTO - Optimize #! statler for use with a solid state drive

Hi

Are you sure you changed the correct line tony? Like I pointed out, which line it appears on varies from system to system.

I am pretty sure that i had changed the correct line on my testing system. grub-update aswell. Maybe i will re-test that again.

Did you test the scheduler out before you altered /etc/grub.d/10_linux?

Yes - and i am doing that right now each time manually after each reboot to have that effect.

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

And did you try using noop or just deadline?

I did this to line 82 ...
linux    ${rel_dirname}/${basename} root=${linux_root_device_thisversion} ro ${args}

And as far as that optimization for opera that you posted, you just type that into the url bar? I don't use Opera so I can't test it out.

Yes - just type that into the url bar and modify the highlghted entry accordingly.

Also if someone knows how to make the same type of modification to chrome that would make a great addition to the guide since it is the default browser.

Sorry - i don't use chrome so i can't test it out.

Last edited by tonyoptical (2011-06-27 20:28:58)

mynis01

#! Die Hard

From: 127.0.0.1

Registered: 2010-07-02

Posts: 1,718

Re: HOWTO - Optimize #! statler for use with a solid state drive

I did this to line 82 ...
linux    ${rel_dirname}/${basename} root=${linux_root_device_thisversion} ro ${args}

This is what the line should all ready look like by default in a fresh install. It's not necessarily going to be line 82 either, it might be different for you. All you need to do is put "elevator=deadline" inbetween "ro" and "${args}".