Are your partitions properly aligned on your SSDs?

[Shining Arcanine]

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:

http://bugs.gentoo.org/show_bug.cgi?id=320655

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?

[erik258]

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?

fdisk follows. Thanks for your input!

Code: Select all

dan@leroy ~ $ sudo fdisk -l /dev/sda

Disk /dev/sda: 64.0 GB, 64023257088 bytes
255 heads, 63 sectors/track, 7783 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x941a4368

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1        2612    20980858+  83  Linux
/dev/sda2            2613        2744     1060290   82  Linux swap / Solaris
/dev/sda3            2745        7783    40475767+  8e  Linux LVM

[Shining Arcanine]

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?

fdisk follows. Thanks for your input!

Code: Select all

dan@leroy ~ $ sudo fdisk -l /dev/sda

Disk /dev/sda: 64.0 GB, 64023257088 bytes
255 heads, 63 sectors/track, 7783 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x941a4368

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1        2612    20980858+  83  Linux
/dev/sda2            2613        2744     1060290   82  Linux swap / Solaris
/dev/sda3            2745        7783    40475767+  8e  Linux LVM

You need to do sudo fdisk -lu /dev/sda to see sectors.

Anyway, while I do not have a particular good example of why you should align your partitions off the top of my head. Here are a few decent examples:

http://www.anandtech.com/show/3667/5
http://www.ocztechnologyforum.com/forum ... rking-life.
http://download.microsoft.com/download/ ... _WH08.pptx

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.

[Shining Arcanine]

I did some more digging around and found the article that brought the need for SSD alignment to light:

http://www.anandtech.com/print/2614

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. :/

[erik258]

I must admit this is a little over my head. Performance tweaking isn't something I spend a lot of time doing, but hey, if I can improve hard disk performance, I may as well.

If you'd be so kind as to lend me a guiding hand, here's my fdisk -lu:

Code: Select all

dan@leroy ~ $ sudo fdisk -lu /dev/sda

Disk /dev/sda: 64.0 GB, 64023257088 bytes
255 heads, 63 sectors/track, 7783 cylinders, total 125045424 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x941a4368

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              63    41961779    20980858+  83  Linux
/dev/sda2        41961780    44082359     1060290   82  Linux swap / Solaris
/dev/sda3        44082360   125033894    40475767+  8e  Linux LVM

Do the + symbols mean I'm not sector aligned?

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.

Code: Select all

dan@leroy ~ $ sudo hdparm -i /dev/sda

/dev/sda:

 Model=CRUCIAL_CT64M225, FwRev=1819, SerialNo=S598947-AFBX-B269009
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=12288
 BuffType=unknown, BuffSize=unknown, MaxMultSect=1, MultSect=1
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=125045424
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4 
 DMA modes:  mdma0 mdma1 mdma2 
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: Unspecified:  ATA/ATAPI-5,6,7

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.

[albright]

Any pointers are appreciated.

I second that - is there a gentoo guide/howto anywhere on this?

[frostschutz]

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.

[Shining Arcanine]

I must admit this is a little over my head. Performance tweaking isn't something I spend a lot of time doing, but hey, if I can improve hard disk performance, I may as well.

If you'd be so kind as to lend me a guiding hand, here's my fdisk -lu:

Code: Select all

dan@leroy ~ $ sudo fdisk -lu /dev/sda

Disk /dev/sda: 64.0 GB, 64023257088 bytes
255 heads, 63 sectors/track, 7783 cylinders, total 125045424 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x941a4368

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              63    41961779    20980858+  83  Linux
/dev/sda2        41961780    44082359     1060290   82  Linux swap / Solaris
/dev/sda3        44082360   125033894    40475767+  8e  Linux LVM

Do the + symbols mean I'm not sector aligned?

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.

Code: Select all

dan@leroy ~ $ sudo hdparm -i /dev/sda

/dev/sda:

 Model=CRUCIAL_CT64M225, FwRev=1819, SerialNo=S598947-AFBX-B269009
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=12288
 BuffType=unknown, BuffSize=unknown, MaxMultSect=1, MultSect=1
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=125045424
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4 
 DMA modes:  mdma0 mdma1 mdma2 
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: Unspecified:  ATA/ATAPI-5,6,7

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.

That is a good question regarding the '+' symbols. I am not sure what they mean myself. My system lacks them:

Code: Select all

$ sudo fdisk -lu /dev/sda 

Disk /dev/sda: 64.0 GB, 64023257088 bytes
255 heads, 63 sectors/track, 7783 cylinders, total 125045424 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x93516c21

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        1024       66559       32768   83  Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2           66560     4260863     2097152   82  Linux swap / Solaris
Partition 2 does not end on cylinder boundary.
/dev/sda3         4260864   125045423    60392280   83  Linux

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.

In your case, you would want to have the following configuration:

/dev/sda1 = [1024, 41962495]
/dev/sda2 = [41962496, 44083199]
/dev/sda3 = [44083200, 125033471]

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.

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.

[completemongerel]

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

[Shining Arcanine]

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.

[erik258]

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.
[ ... ]

/dev/sda1 = [1024, 41962495]
/dev/sda2 = [41962496, 44083199]
/dev/sda3 = [44083200, 125033471]

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.

Here again for easy reference are the relevant parts of my fdisk -lu:

Code: Select all

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              63    41961779    20980858+  83  Linux
/dev/sda2        41961780    44082359     1060290   82  Linux swap / Solaris
/dev/sda3        44082360   125033894    40475767+  8e  Linux LVM

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: Select all

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.

Let's assume I'd rather grow sda1 than shrink it, to keep my numbers consistent with the example.

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: Select all

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: Select all

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 ... isksdth-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.

[Shining Arcanine]

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:

http://www.anandtech.com/print/2738/1

[jordanwb]

if this were any further over my head i'd be on mars.

I'm orbiting Jupiter right now.

[dmpogo]

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.

[Shining Arcanine]

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.

[frostschutz]

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.

[dmpogo]

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

[Shining Arcanine]

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.

[devsk]

Easiest way to align the partitions is to use something like:

Code: Select all

fdisk -H 128 -S 32 /dev/sda

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.

[truekaiser]

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?

[completemongerel]

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;

Code: Select all

[root@myhost lg]# hdparm -t /dev/sda

/dev/sda:
 Timing buffered disk reads:  770 MB in  3.00 seconds = 256.30 MB/sec

but... 

[root@myhost lg]# fdisk -lu

Disk /dev/sda: 50.0 GB, 50020540416 bytes
255 heads, 63 sectors/track, 6081 cylinders, total 97696368 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0003cdb5

Device Boot Start End Blocks Id System
/dev/sda1 * 63 208844 104391 83 Linux
/dev/sda2 23985045 97691264 36853110 83 Linux
/dev/sda3 8610840 23985044 7687102+ 83 Linux
/dev/sda4 208845 8610839 4200997+ 83 Linux

Partition table entries are not in disk order

Disk /dev/sdb: 3965 MB, 3965190144 bytes
122 heads, 62 sectors/track, 1023 cylinders, total 7744512 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System

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.

cm

[dmpogo]

Easiest way to align the partitions is to use something like:

Code: Select all

fdisk -H 128 -S 32 /dev/sda

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

[Shining Arcanine]

Easiest way to align the partitions is to use something like:

Code: Select all

fdisk -H 128 -S 32 /dev/sda

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.

[HeissFuss]

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

Here's my disk after GPT partitioning:

Code: Select all

# gdisk -l /dev/sdh
GPT fdisk (gdisk) version 0.6.8

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdh: 195371568 sectors, 93.2 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 87FFF7CE-540E-4DF2-9EF2-6059B3855B3F
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 195371534
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048            4095   1024.0 KiB  EF02  BIOS boot partition
   2            4096          135167   64.0 MiB    0700  Linux/Windows data
   3          135168       195371534   93.1 GiB    8E00  Linux LVM

As you can see, all partitions are aligned to 2048 sectors with the exception of the end of the largest partition (which is ok).


LVM creation:

This used to be a hassle because you needed to align it by messing with different metadata sizes for the PVs. Now though, there's a simple --dataalignment option for pvcreate.

First, if you don't specify the alignment when creating your PV, it will start at a weird offset (in my case 192K). To avoid that, we specify the offset.

Code: Select all

# pvcreate /dev/sdh3 --dataalignment 512K
  Physical volume "/dev/sdh3" successfully created
# pvs /dev/sdh3 -o+pe_start
  PV         VG   Fmt  Attr PSize  PFree  1st PE
  /dev/sdh3       lvm2 a-   93.10g 93.10g 512.00k

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.

Here's the relevant portion of my /boot/grub/grub.cfg

Code: Select all

menuentry "Gentoo GNU/Linux, with Linux x86_64-2.6.34-gentoo" --class gentoo --class gnu-linux --class gnu --class os {
        insmod ext2
        set root='(hd8,2)'
        search --no-floppy --fs-uuid --set 87b0e6f1-d00a-4fe3-b39e-6b830707672b
        echo    Loading Linux x86_64-2.6.34-gentoo ...
        linux   /kernel-genkernel-x86_64-2.6.34-gentoo root=UUID=c817e1c1-baa8-4173-90b1-19e00589f55c ro domdraid dolvm
        echo    Loading initial ramdisk ...
        initrd  /initramfs-genkernel-x86_64-2.6.34-gentoo
}

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.

[pigeon768]

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

Code: Select all

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

or

Code: Select all

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.