I thought I had my partitions aligned on my laptop's SSD, but I just discovered that they were not aligned properly. When I installed Gentoo, my boot partition was properly aligned, but my swap and root partitions were off proper alignment by 1 sector and 2 sectors respectively. I just filed a bug report regarding it:

Did anyone else make the same mistake I did, or did you realize that the partition boundaries ended 1 sector after where they should have ended and corrected it manually when you installed Gentoo on your SSDs?

Interesting. It almosts looks as if my SSD is not partitioned on a sector boundary. Since it seems to have worked for you without alignment, may I ask why it matter and what changes I might expect to see if I resized my partitions? I fantasize that it will greatly increase throughput... but in reality, I don't see how it could. Besides, I don't even know if my SSD has 4k sector sizes; maybe it only has 512 byte sectors?

Interesting. It almosts looks as if my SSD is not partitioned on a sector boundary. Since it seems to have worked for you without alignment, may I ask why it matter and what changes I might expect to see if I resized my partitions? I fantasize that it will greatly increase throughput... but in reality, I don't see how it could. Besides, I don't even know if my SSD has 4k sector sizes; maybe it only has 512 byte sectors?

The benchmarks at Anandtech's site show an improvement that can vary from 10% to 200%, depending on what SSD you use. That review was not specifically regarding partition alignment, but from reading their articles, you can realize that it has an effect. There several threads at ocz's forums dedicated to partition alignment and their customer support there has guidelines for how to do it specifically for performance reasons. Lastly, Microsoft has some slides explaining why unaligned partitions cause problems in SSDs and saying what they did in Windows 7 to fix that.

While it did not argue for alignment, all of the information necessary to see what happens when a drive is misaligned is there. Usually, the better drives cope well with misalignments, but all of them suffer to some extent when they are misaligned. Enthusiast circles, such as those on OCZ's forums, realized soon afterward that aligning drives makes a difference.

Also, after re-reading that article, I realized that I was wrong to align my SSD to 64KB boundaries. My SSD needs to be aligned to 512KB boundaries, because that is the erase block size. The starting sector needs to be 1024 on my SSD. :/

I have nothing particularly special, just a mid-range SSD from around january. I bought it because I was worried my platter drive would break if I kept biking around with it in my backpack, but the speed boost is a great fringe benefit.
Not sure if it's particularly susceptible to degraded performance due to misalignment.

I'd be happy to realign my partitions, if I thought it would make sense to do so. But I don't really understand how I would do such a thing. Any pointers are appreciated._________________Configuring a Firewall? Try my iptables configurationLinuxCommando.com is my blog for linux-related scraps and tidbits. Stop by for a visit!

I second that - is there a gentoo guide/howto anywhere on this?_________________.... there is nothing - absolutely nothing - half so much worth
doing as simply messing about with Linux ...
(apologies to Kenneth Graeme)

I don't have a SSD, but a 4k sector HDD drive, that claims to be a 512b sector drive to the OS (WD15EARS). So you have alignment problems there too.

This whole alignment business is new, and unfortunately many things still align with 512 bytes (even though a 4k alignment wouldn't really hurt a 512b disk either).

So basically what you have to do is align manually. At least that's what I did with my disk.

So find out what alignment you need (depends on your device). Then go into the partitioning program of your choice (I used parted for GPT partitions) and make it use 512b sectors as units (or see if it supports your alignment - in my case it didn't as my drive is not recognized as 4k drive). Then create the partitions, which each starting sector using the correct align (in my case dividable by 8, since 8 512byte sectors = 4k). Ideally the size of the partition should also be a multiple of your alignment (in my case x*4k, i.e. x*8 512b sectors). Whether that makes a difference depends on whether your storage system stores metadata at the beginning (most filesystems do) or end (hello software raid superblock 0.9).

The alignment must also be respected by all layers you put on the drive, i.e. not only partitions, but raid (stripe size, payload offset?), lvm (payload offset?), filesystems (block size?), etc.

I have nothing particularly special, just a mid-range SSD from around january. I bought it because I was worried my platter drive would break if I kept biking around with it in my backpack, but the speed boost is a great fringe benefit.
Not sure if it's particularly susceptible to degraded performance due to misalignment.

All SSDs suffer from lower performance when their partitions are misaligned, although some suffer particularly more severely than others. Well made SSDs such as Intel's do not exhibit significant performance losses when their partitions are misaligned. If your SSD is a good one, properly aligning your partitions could give you a small boost. More recent SSDs, specifically Sandforce based SSDs, exhibit an enormous boost when their partitions are properly aligned, although their performance in a misaligned state is high enough that you would not notice the issue.

You can align your SSDs by making your partitions start and end on erase block boundaries. Modern SSDs have 1024 sector erase block boundaries, so all partitions must begin on a multiple of that and end on a multiple of that minus 1. Therefore, aligned partition boundaries must be of the form [u, v], where u is a function u(x) = kx, v is a function v(y) = ky - 1, x < y, x and y are positive integers and k is 1024.

Microsoft recommends is that k be 2048 for better compatibility, but no SSD uses 2048 sector erase blocks at this time. Because erase block boundaries are powers of two, someone designing an installer that would be used on future SSDs would want to pick a value of k such that k(z) = 2^(10 + z) where z is a non-negative value. At the moment, z = 0, but it is likely that future SSDs would have z = 1.

Note that you can have /dev/sda3 end at the end of the drive. Having it end at an erase block boundary is so that the partition after it can start at a sector boundary, but in the case of /dev/sda3, there is no sector boundary after it, so as far as I know, you can have it end arbitrarily. Whether or not this matters depends on how your file system works, so it might be a good idea to have it end at an erase block boundary.

frostschutz wrote:

I don't have a SSD, but a 4k sector HDD drive, that claims to be a 512b sector drive to the OS (WD15EARS). So you have alignment problems there too.

This whole alignment business is new, and unfortunately many things still align with 512 bytes (even though a 4k alignment wouldn't really hurt a 512b disk either).

So basically what you have to do is align manually. At least that's what I did with my disk.

So find out what alignment you need (depends on your device). Then go into the partitioning program of your choice (I used parted for GPT partitions) and make it use 512b sectors as units (or see if it supports your alignment - in my case it didn't as my drive is not recognized as 4k drive). Then create the partitions, which each starting sector using the correct align (in my case dividable by 8, since 8 512byte sectors = 4k). Ideally the size of the partition should also be a multiple of your alignment (in my case x*4k, i.e. x*8 512b sectors). Whether that makes a difference depends on whether your storage system stores metadata at the beginning (most filesystems do) or end (hello software raid superblock 0.9).

The alignment must also be respected by all layers you put on the drive, i.e. not only partitions, but raid (stripe size, payload offset?), lvm (payload offset?), filesystems (block size?), etc.

That is correct, but so far, I have only paid attention to partition boundaries. Do you know any specifics on how to force ext4 to align to specific boundaries?

By the way, dealing with your advanced format hard drive is easier than dealing with SSDs, because with your drive only have to worry about sectors while SSDs have both pages (smallest unit that can be written) and erase blocks (smallest unit that can be erased). It is my understanding that SSD pages are 4KB in size, which is 8 sectors while SSD erase blocks are 128 pages, which is 512KB in size and therefore 1024 sectors. On your advanced format drive, you just need to start your partition at sector 64 (because anything prior to sector 63 is reserved) to align your partitions. You can use k = 8 in the equations I posted above, because there is no distinction between writing and erasing on mechanical hard drives.

Also, when you are doing RAID 0, it is my understanding that you want to multiple the value of k by the number of drives in use, so if you have 4 SSDs in RAID 0, you want k = 4 * 1024 = 4096.

i've just got an ssd. if this were any further over my head i'd be on mars. is there a concise guide anywher to deal with this? or better still \software that'll do it for me

How do you want to partition your drive? I partitioned mine by following the Gentoo manual with two minor changes. One, I used a 2GB swap partition and two, I made certain that the partitions were properly aligned. If you want to do the same, you could just press 'u' when you open fdisk and when you make the partitions, you could specify the exact sectors that I used for my SSD, although you will likely need to let fdisk automatically choose the last sector for the root partition. Pressing 'u' will cause fdisk to ask for sector numbers when you make partitions, so you will not need to worry about how you should specify them.

Whew, thanks for making it sound like a math assignment. Kidding. Very well defined. Thank you. I am going to try to walk through how you got these numbers for my partitions, so others can apply these concepts for themselves. Then, hopefully soon, I'll back up my data and see what happens when I re-align.

My sda1 starts on 63. This is not sector-aligned. It should start on 1024. (lowest possible x, since 0 is not an option).
It ends on 41961779. By running a modulus operation on that number, I can see how far off it is from the end of the nearest erase block (I used bc for this; note that I left the scale - or precision - to 0, so that the modulus gave me a whole remainder. )

Code:

41961779/1024=40978
41961779%1024=307

So my sda1 went 308 blocks past where it should. (Remember, we want sda1 to end on the last sector before the next sector boundary, so that sda2 can end on a sector boundary. Thus I add 1 more to the number of blocks past the sector boundary). Thus I can either shrink sda1 by 308 blocks down to 41961471 so that sda2 can begin on a sector boundary at 41961472, or I can grow it by 1024-308 or 716 blocks, so that it ends at 41962495. In that case, sda2 would begin at 41962496, which is the next sector boundary on the disk.

My sda2 then would logically start at the next sector boundary, 41962496. Let's apply the same logic to the end of sda2. I currently have it ending at 44082359.

Code:

44082359%1024=183
183+1=184

My sda2 is 184 blocks too long. I can either shorten by that amount, giving me an ending block of 44082359-183-1=44082175, or I can lengthen it by (1024-184), or 840. That would give me an ending block of 44083199.

Again, for consistency, let's assume I choose to grow sda2 to 44083199.

Finally, I have one more partition. Clearly I'll have to change it's starting place to compensate for the increased size of sda2. 44083200 becomes the starting point for sda3.

Now we discuss the end of sda3. Shining Arcanine suggests that ending sda3 on a sector boundary is not beneficial from the partition perspective, because there is no next partition to start on a sector boundary. However, since some filesystems apparently prefer a sector boundary, let's do the math once more and determine where I'd align sda3 to end on a sector boundary.

Code:

125045424%1024=688.
688+1=689.
125045424-689=125044735

.

Oh oh! I've got a different number for the end of sda3. For whatever reason, Shining Arcanine moved my sda3's ending position back 11 sectors from the end of the last sector-aligned ending position. Both his numbers and mine are sector aligned; from what I can tell, he just got some numbers wrong somewhere (or i did) and ended up skipping a little bit more space at the end of the disk than I did.

Shining Arcanine, I'd love it if you'd look this over and affirm that I'm telling these people the right thing : )

Now let's talk a little bit about filesystems and lvm. IBM Has produced a wonderful article about different filesystem penalties on misaligned partitions:
http://www.ibm.com/developerworks/linux/library/l-4kb-sector-disks/index.html?ca=dgr-lnxw074KB-Disksdth-LX
This article suggests that all filesystems should see a modest performance increase if sector aligned. The improvement for btrfs is neglegable, and actually substantial for Reiser, which is the filesystem I typically use. So The long an the short of it is, sector alignment is probably a very good idea for everyone. Furthermore, the article did touch on LVM, in effect saying that LVM volumes also benefit from alignment of the underlying physical volume (ie partition).

Let's take this one step further. The article is written with 4k-sector HDDs in mind, not solid state drives. It does hint that 4k alignment would be more appropriate for some devices than would the 1k alignments described here. Does anyone have any input on whether 4k alignment would be a good idea even on solid state drives?

Hope it helps, and hope I get a chance to do this to my hard drive in the near future. I'll have to take it out and back it up first, which I'll probably do with a good old DD, and then do some resizings of partitions and filesystems on it. I hope to do this nondestructively, but I'm not sure whether I can pull this off. Stay tuned; I hope to report back here on methodology and performance increase, if any._________________Configuring a Firewall? Try my iptables configurationLinuxCommando.com is my blog for linux-related scraps and tidbits. Stop by for a visit!

Erik258, you are right about what I said with one minor error. I moved your partition boundary back by 11 erase blocks, not sectors. Traditionally sectors are used to describe a unit on mechanical hard drives, which are 512 bytes in length. SSDs use different types of units, which are pages (smallest unit that can be written) and erase blocks (smallest unit that can be erased). Since fdisk was made for mechanical hard drives that use 512 byte sectors, it defines a sector as being 512 bytes and to align data properly on old hard drives, it requires that all partitions be defined in units of either sectors or cylinders. Cylinders are another unit that is just a multiple of sectors and for the sake of simplicity, I will avoid an explanation of exactly what they are. Anyway, because fdisk defines a sector as being 512 bytes, it becomes necessary to use a different term to refer to the basic unit of alignment on SSDs. Since on SSDs, the basic unit of alignment is the erase block, it makes sense to call them that.

I make a mistake on the ending boundary of your /dev/sda3 partition. My error was caused by the fact that I had looked at where your current partition was and decided that was the end of the disk and moved it back. Apparently, this was not the case. When your disk was partitioned, the end of your /dev/sda3 partition was not placed at the end of the disk. This is likely because your disk was being aligned to cylinders, rather than sectors, which are a bigger unit. This is because cylinders are the default units in fdisk and this results in wasted space at the end of the drive of up to (but not including) 1 cylinder.

With regard to 1K and 4K alignments, I am a bit confused as to whether you mean KiloBytes or KiloSectors, where 1K = 2^10 = 1024. Here I am suggesting 1024 sector alignments, which are 512KB in size. 4KB alignments are 8 sectors in size. The reason for having 512KB alignments on SSDs is because erase blocks on modern SSDs are 512KB. There is a good description of why 512KB erase blocks are significant in an article on SSDs at Anandtech.com:

By the way, dealing with your advanced format hard drive is easier than dealing with SSDs, because with your drive only have to worry about sectors while SSDs have both pages (smallest unit that can be written) and erase blocks (smallest unit that can be erased). It is my understanding that SSD pages are 4KB in size, which is 8 sectors while SSD erase blocks are 128 pages, which is 512KB in size and therefore 1024 sectors. On your advanced format drive, you just need to start your partition at sector 64 (because anything prior to sector 63 is reserved) to align your partitions. You can use k = 8 in the equations I posted above, because there is no distinction between writing and erasing on mechanical hard drives.

And the drive in question (well at least its 1Tb cousin) has a jumper 'for windows XP' which cheats the drive think the first partition starts at sector 64.

By the way, dealing with your advanced format hard drive is easier than dealing with SSDs, because with your drive only have to worry about sectors while SSDs have both pages (smallest unit that can be written) and erase blocks (smallest unit that can be erased). It is my understanding that SSD pages are 4KB in size, which is 8 sectors while SSD erase blocks are 128 pages, which is 512KB in size and therefore 1024 sectors. On your advanced format drive, you just need to start your partition at sector 64 (because anything prior to sector 63 is reserved) to align your partitions. You can use k = 8 in the equations I posted above, because there is no distinction between writing and erasing on mechanical hard drives.

And the drive in question (well at least its 1Tb cousin) has a jumper 'for windows XP' which cheats the drive think the first partition starts at sector 64.

That works too, but that could lead to confusion down the road. I use fdisk to properly partition drives.

You shouldn't use this jumper for Linux... it's only for Windows XP really. It adds an offset to the drive that makes the Windows XP standard install (one partition whole drive) just happen to be 4k aligned.

In Linux (and if you're tech savvy in Windows too) you're better off aligning it directly and you can not do that anymore with the jumper because with it, you won't know what the right offset is anymore.

You shouldn't use this jumper for Linux... it's only for Windows XP really. It adds an offset to the drive that makes the Windows XP standard install (one partition whole drive) just happen to be 4k aligned.

In Linux (and if you're tech savvy in Windows too) you're better off aligning it directly and you can not do that anymore with the jumper because with it, you won't know what the right offset is anymore.

sure. In few days I have to deal with this disk on my wife's Mac, which I know little about I wonder if it has fdisk on its *BSD level

You shouldn't use this jumper for Linux... it's only for Windows XP really. It adds an offset to the drive that makes the Windows XP standard install (one partition whole drive) just happen to be 4k aligned.

In Linux (and if you're tech savvy in Windows too) you're better off aligning it directly and you can not do that anymore with the jumper because with it, you won't know what the right offset is anymore.

sure. In few days I have to deal with this disk on my wife's Mac, which I know little about I wonder if it has fdisk on its *BSD level

I am not familar with Mac OS X, but as far as I know, it is BSD with Apple's eye candy running on top of it, so the instructions in this thread should work for it.

while creating the partition table. You get cylinders of 2MB each. Every partition except for the first is aligned automatically. Since I typically create a 100MB boot partition as first partition, that gets taken care of because boot is not really performance sensitive.

One thing to note, and which has not been mentioned so far, is that when you create extended partitions (lets say you want more than 4 partitions), you need to be extra careful for aligning because the first logical partition inside the extended partition will get a 16KB offset in the beginning e.g. if your extended partition is /dev/sda4 and it starts at cylinder 2034, you first logical partition /dev/sda5 will also appear to start on cylinder 2034 in 'fdisk -l /dev/sda' output but will have an offset of 16KB applied to it. That can be seen in 'fdisk -lu /dev/sda'. In this case, it is better to use -u option and create logical partitions at sector level and just skip 512KB (assuming your drive's erase block size is 512KB) instead of 16KB.

PS: Disk geometry is of no consequence in SSD world, so "-H 128 -S 32" is not insane.

i am looking to get another 1tb drive and i have a choice to get one of these new 4k sector drives. i am planning on using a single partition on it. is there any special options in the kernel i have to turn on to take advantage of this or does any kernel after 2.6.31 do it automagicly if detected?_________________"My father rode a camel. I drive a car. My son flies a jet-plane. His son will ride a camel."
Saudi saying
Too late to do anything about it, so just sit back and enjoy the fireworks.

hey all, i'm still watching this thread with interest. i went over to arch for a while but i had gentoo on my boxes since 2001 and i miss it on this one. nothing's as lean as a gentoo install.
i i managed to always get close to this with arch;

from what i've gleaned the crosses after partitions 3 & 4 means that there is overlap between partitions. correct? is that because they were aligned to cylinder boundaries? sda4 is actually near the start of the ssd and sda3 is fairly close to the start of the disk too as the first 2 partitions are small. i haven't been able to correct this yet but it doesn't seem to impact performance that i'm aware of as the advertised throughput is achieved but i have to be suspicious that this must impact performance in some way. my sector size is 512 should it be corrected 1024? would this be more efficient in terms of performace? ahh, so many questions and so little grey matter to answer them myself . i'm hoping a gentoo only lappy will smoke those hdparm figs and i get it right. i've gotta get the partitions right 1st.

i'll keep posting as the fresh install progresses from tomorrow. any and all info/suggestions welcome before i format.

while creating the partition table. You get cylinders of 2MB each. Every partition except for the first is aligned automatically. Since I typically create a 100MB boot partition as first partition, that gets taken care of because boot is not really performance sensitive.

One thing to note, and which has not been mentioned so far, is that when you create extended partitions (lets say you want more than 4 partitions), you need to be extra careful for aligning because the first logical partition inside the extended partition will get a 16KB offset in the beginning e.g. if your extended partition is /dev/sda4 and it starts at cylinder 2034, you first logical partition /dev/sda5 will also appear to start on cylinder 2034 in 'fdisk -l /dev/sda' output but will have an offset of 16KB applied to it. That can be seen in 'fdisk -lu /dev/sda'. In this case, it is better to use -u option and create logical partitions at sector level and just skip 512KB (assuming your drive's erase block size is 512KB) instead of 16KB.

PS: Disk geometry is of no consequence in SSD world, so "-H 128 -S 32" is not insane.

Don't know, I tried doing that on my new install, and all partitions end sectors were 'off by one'. I.e I start say at at 1024, add + 128Mb, and my end sector will be divisible by 8, not the beginning of the next partition. So I went with -u explicit sector count

while creating the partition table. You get cylinders of 2MB each. Every partition except for the first is aligned automatically. Since I typically create a 100MB boot partition as first partition, that gets taken care of because boot is not really performance sensitive.

One thing to note, and which has not been mentioned so far, is that when you create extended partitions (lets say you want more than 4 partitions), you need to be extra careful for aligning because the first logical partition inside the extended partition will get a 16KB offset in the beginning e.g. if your extended partition is /dev/sda4 and it starts at cylinder 2034, you first logical partition /dev/sda5 will also appear to start on cylinder 2034 in 'fdisk -l /dev/sda' output but will have an offset of 16KB applied to it. That can be seen in 'fdisk -lu /dev/sda'. In this case, it is better to use -u option and create logical partitions at sector level and just skip 512KB (assuming your drive's erase block size is 512KB) instead of 16KB.

PS: Disk geometry is of no consequence in SSD world, so "-H 128 -S 32" is not insane.

Don't know, I tried doing that on my new install, and all partitions end sectors were 'off by one'. I.e I start say at at 1024, add + 128Mb, and my end sector will be divisible by 8, not the beginning of the next partition. So I went with -u explicit sector count

After you specify the first partition manually, you can use 'c' to toggle DOS compatibility, that will disable the off by the one issue, allowing you to do +128M and actually make partitions of size +128M, rather than +128M and one extra sector.

I'll add to this topic I'm setting another of these up and will try to record my steps.

I'm going to use GPT + GRUB2 + LVM. The LVM steps can also be applied to MBR/fdisk created partitions, assuming that you aligned them like previous posts mention. If you don't care about LVM, you'd be better off using ext4 on top of a partition so that you'd keep TRIM support (ext4 on top of lvm doesn't allow TRIM at this time.)

If you have the option of using GPT and use gdisk to create your partitions, there is no issue with alignment since by default now gdisk aligns on 2048 sector (1MB) boundaries. The first partition starts at 2048, and it also rounds to the nearest 2048 at the end of each partition you specify. I'm not dual booting, but I expect Windows would have issues with GPT if you did.

Using GPT, there are a couple of remaining issues. As I understand it, using GPT with Grub 1 can be complicated. For my system, I set it up with GRUB2, so it's simpler.

GPT partitioning:
Create a first partition of 1MB size and type EF02 (grub2 boot partition)
Create a second partition of 64MB for /boot, type ext3
Create a third partition of the rest of the disk for LVM, set type to 8E00

There's an additional new option to pvcreate, --dataalignmentoffset <offset>, which I think may be able to correct for a misaligned partition. If you have the luxury of being able to wipe your partition anyway for a pvcreate, you may as well just go recreate it correctly aligned...

After creating your VG and LVs, there's an option that can be used with ext4 to try not to cross stripe width barriers within the filesystem.
mkfs.ext4 -E stripe-width=128 /dev/vg/lv

This setting is intended for raid arrays, but there's a possible gain for SSD write alignment also. It is in filesystem blocks, so I've specified 128 * 4K = 512K for stripe-width.

GRUB2:

I followed the Gentoo Wiki guide on installing GRUB2. I used genkernel with LVM enabled against a manually configured kernel (don't forget to build in EFI Partition support which is necessary for GPT.)

Surprisingly, this all worked out and booted perfectly. I don't think that's ever happened before.

With the exception of the dolvm portion, which I'm not even sure is necessary, it was all autogenerated by grub-mkconfig and installed with grub2-install /dev/sdh. The "dolvm" can be configured to be added automatically with an option in /etc/default/grub. I'm not sure why Gentoo doesn't provide a skeleton for that config file since other distros do.

Wow, all this shit is way more complicated than it needs to be. Just create your partition table with:

Code:

cfdisk -h 128 -s 32 /dev/sd<whatever>

or

Code:

fdisk -H 128 -S 32 /dev/sd<whatever>

Make sure you start with a fresh partition table too. Every single partition, except for the first partition on the disk, will be aligned to a 2MB boundary - and by extension, a 4096 byte boundary. The first partition is usually /boot, and you don't need speed on your /boot disk.

If you decide you do want your /boot partition to be aligned, create the smallest possible partition you can at the beginning of your disk, then create the boot partition after it, and then delete the spacer partition._________________My political bias.