Partition alignment tester

01.07.2010 19:52

Lenovo Thinkpad T61 I use at work has abysmal IO performance. The whole system becomes unusable if some process starts moving gigabytes of data around the disk (not so uncommon when dealing with, say, Wikipedia dumps).

This is also noticeable at boot: 75 seconds from power-on to login prompt, then 45 seconds to get to a usable GNOME desktop and a further half a minute to start Firefox. All the time the hard drive disk LED is constantly lit up (which always reminds me of how Windows 95 used to boot). This is on stock Debian Squeeze (but was the pretty much same on Lenny)

Since colleagues running Windows on the same hardware don't complain about such problems I thought that maybe the problem was in the way I partitioned the disk. See, the computer came preinstalled with Vista, which I promptly deleted. I also repartitioned the disk while installing Debian. If the disk is one of those with 4 KB physical block size perhaps the new partitions I made are misaligned?

This laptop is now a bit over 2 years old and as far as I know 4 KB blocks weren't used back then (hence my ignorant repartitioning). But perhaps Lenovo was a little ahead of time?

Unfortunately it's impossible to reliably tell the physical block size from the information reported by the disks' firmware (dirty details here). For instance, WD EARS disk in my Desktop plainly reports 512 B physical sectors even though I'm certain it uses 4 KB ones.

So I made a little tool that reads or writes 4 KB blocks from a partition with different alignments and measures the throughput. On a disk where logical and physical block size differ, throughput should be significantly lower on unaligned accesses because the disk must do multiple physical accesses per single logical operation.

Here are the measurements on the Thinkpad:

Writing to /dev/raw/raw1
Size 514805760 bytes, reported FS block size 0
10 processes, each writing 100 * 4096 bytes
align	elapsed	throughput
0	3 s	1.3 MB/s
1	3 s	1.3 MB/s
2	3 s	1.3 MB/s
3	4 s	1.0 MB/s
4	3 s	1.3 MB/s
5	3 s	1.3 MB/s
6	3 s	1.3 MB/s
7	3 s	1.3 MB/s

And here on my desktop with WD EARS drive:

Writing to /dev/raw/raw1
Size 514805760 bytes, reported FS block size 0
10 processes, each writing 100 * 4096 bytes
align	elapsed	throughput
0	3 s	1.3 MB/s
1	35 s	0.1 MB/s
2	37 s	0.1 MB/s
3	38 s	0.1 MB/s
4	39 s	0.1 MB/s
5	38 s	0.1 MB/s
6	38 s	0.1 MB/s
7	39 s	0.1 MB/s

As you can see Thinkpad has the same throughput regardless of the alignment while unaligned accesses get a huge penalty on my desktop. Head seek time dominates in these measurements, hence the relatively low maximum throughput on both machines.

I tried to cancel the effect of any caches the best I knew in my code but with all the magic that sits between a write() call and the physical platter on a modern system it's impossible to be sure. Still I think this is a pretty strong indicator that partition alignment isn't the cause of the performance problems here. And it's also a pleasant confirmation that I did properly set up partitions on my desktop (Ted has a really good guide how to do that - just ignore the fact that he is talking about SSDs)

You can get the alignment tester code from git:

git clone

Make sure you read the source and understand what it does before running. Also you will need a scratch partition because tests are destructive (I used the swap partition on both machines for that). Oh, and do a full backup first.

Posted by Tomaž | Categories: Code

Add a new comment

(No HTML tags allowed. Separate paragraphs with a blank line.)