Easy way to align Linux partitions for SSD and myths debunked

Recently I got a laptop from my employer with an Intel X25-M SSD drive in it. I have spent some time trying to figure out the best and easiest way to install Linux onto it while retaining the Windows 7 (so I have to use MBR instead of GPT). There are numerous discussions you can find on the net, some of them are quite complex and some are simply misleading (if not wrong). In fact this task is quite easy with modern Linux and here's a documentation of what I've done. This blog is not meant to be a full discussion on this topic, but only intended as a cheat sheet for those experienced Linux users (if you want a more detailed and correct discussion on this topic, I recommend Ted Ts'o's blog: Aligning filesystems to an SSD’s erase block size.)

For those impatient readers, here's an overview: the disk geometry (or C-H-S value) you see from partition programs as well as the warning about partitions are not aligned to cylinder boundary don't matter at all so there's no point to spend time on tuning loose knobs. New GParted (I used 0.7.1 from SysRescueCD, not to be confused with "GNU parted") is a very easy to use tool and it now defaults to create partitions aligned on 1 MiB (I heard that Ubuntu 10.10 and later can do partition alignment automatically too but I haven't tried that).

Here's the detail:

The myth: Does the C-H-S value still matter?

A lot of discussions were about checking the disk geometry after partitioning. However, in fact no modern operating system pays attention to those values any more (see the comment by Ted Ts'o). And those "-H xx -S xx" options passed to fdisk are only meant to make that fdisk program happy so it can create partitions aligned with cylinder boundaries. Although the C-H-S values are stored in MBR, they are not used by the Linux kernel who runs the whole system. Instead of paying attention to choosing or checking those C-H-S values, you should only need to make sure that the start and end sectors of partitions are multiples of the size of your erase block. Of course you can use any good partition programs to do this.

So you don't have to use that fdisk program

and you can simply choose any program that you are familiar with. For me I'm comfortable with sfdisk and GParted. This time I tried latest GParted and was very happy to see it had supported partition alignment on 1 MiB boundary. So my work is done in one minute without using a calculator. After that I also carefully checked the partition table with "sfdisk -uM" and was sure that those partitions were aligned on MiB boundaries. The extended partition was not aligned but I thought that didn't matter as long as all logical partitions in it were aligned correctly.

A few more tips:

• If you want to have TRIM/DISCARD support you can use a 2.6.33+ kernel with Ext4 file-system, mounted with -o discard.


• When making the Ext4 file-system, make sure you use the stripe-width option and let it align with erase block boundary too (see Ted's post above).


• Don't use LVM or dm-crypt since they don't support TRIM/DISCARD command yet. Newer kernel supports TRIM/DISCARD passing along in LVM and dm-crypt.

compilebench test result:

Intel's X25-M is very smart that even if you don't align the access correctly the drive will do magic under the hood so the initial benchmark data doesn't differ too much, however, the performance will degrade much more quickly as the internal mapping tables getting more and more complex due to unaligned writes. Here I post the file-system benchmark result when it's still new. I'll try to do benchmark again after several months to see if there's any performance degrade (although my usage is not heavy).

I used compilebench v0.6 because I think it mimics daily desktop usage very well.

Machine spec:
System: Debian Squeeze (testing)
Kernel: 2.6.37-rc5-amd64 from Debian experimental repo
Test command: sudo ./compilebench -D t -i 10 --makej (the same option used by Phoronix Test Suite)
File system: Ext4, mount option: rw,noatime,discard

compilebench Initial Create test result: 105.24 MB/s (on 2010-12-27).

MeeGo: Auto-Start an Application on Session Start

For modern Linux desktop, it's a common way to auto-start an application in a user-session by placing a ".desktop" file into /etc/xdg/autostart. But if you are writing or porting an application to MeeGo and found that the application is not auto-started after you put in a seemingly correct .desktop, please check this:

If there's an "OnlyShowIn=" item, it must contain the string X-MOBLIN-NB. For example:

OnlyShowIn=GNOME;X-MEEGO-NB

Another caveat is that MeeGo's uxlaunch doesn't honor AutostartCondition key yet, for the sake of simplicity and fast-boot.

For code under the hood, check MeeGo's uxlaunch/desktop.c.

Very hard to make bootable USB drive from Ubuntu 10.10's CD Image

I was spoiled by MeeGo's super convenient USB live image so I was very surprised when I found that it was very hard to make a bootable USB drive from Ubuntu 10.10's CD-ROM image for my wife.

On Linux, Ubuntu only officially supports making bootable USB drive from its CD-ROM image by using "ubuntu-usb-creator", which is not available in any Linux installations I'm using now (MeeGo, Debian, CentOS). Ubuntu's official help document mentions one alternative way -- to download a small image and combine it with the iso file -- doesn't work, and community posts pointed out that that methods only worked with "alternative iso" (not desktop iso).

Finally I found a way (and the only way) to make a usable USB drive for installation is from this post.

So what? I think Canonical really should release official USB images since most netbooks shipped today have no CD-ROM drive.