Bdtyktl

I am familiar with what partitions are, but I saw a question about aligned partitions on Ask Ubuntu, and realised I didn't know what "aligned partitions" are.

So what does it mean to "align" partitions? What are the benefits, and the downsides?

Aligning the partition means to align it to match the true, underlying block structure.

For a long time now hard disks have used 512 byte blocks. Because this has gone on for a long time it is now almost impossible to change the block size. Too much software would need to be fixed.

On an SSD the true block size could be 128 KB. On a RAID array it might be 64 KB. On an advanced format drive it will be 4 KB.

For backward compatibility the drive continues to work with 512 byte blocks. But for performance reasons your system really should know the true block size.

On of the easiest performance tweaks to make is to align the drive partition with the true block size so that when your OS does write 4 KB or 64 KB or 128 KB it writes a full block.

If the partition was not aligned then the result would be to write 512 bytes to the first block and 4K - 512 bytes to the second block, forcing the disk/SSD/RAID to do two read-modify-write cycles instead of one write.

Partitions are sequences of blocks, and by long-standing convention one block is 512 bytes.

So a partition may start at any multiple of 512 bytes inside a disk, "seen" as a very long string of bytes.

The underlying disk hardware, though, which originally had the same 512 byte sector size, uses now a larger size for efficiency. Let's say it's 4096 bytes.

For compatibility reasons, the firmware standing between the OS and the hardware still "talks in sectors". So you ask the first sector, and the hardware retrieves the first block (4096 bytes), and the firmware extracts and delivers the appropriate slice. You ask the second block and the block is probably retrieved from the cache.

So far sector size mismatch has no cons.

But the OS also employs blocks (usually called clusters) for efficiency, and will align them to the partition. So a 4-sector cluster will be made up of sectors 5, 6, 7 and 8.

When the OS requests filesystem cluster #2, the firmware gets asked for logical sectors 5, 6, 7, and 8. If they are all in the same disk block, then the disk has to perform ONE read.

But if the partition starts at the "wrong" sector, the first cluster in the filesystem will for instance end up, simplifying, at sectors 2, 3, 4 and 5. And they might then be be half in the first disk block (1-2-3-4), half in the second (5-6-7-8).

You now need one extra read. For OS-to-disk ratios of 1:1, this is the same as doubling the reads. If OS-to-disk ratio is 2:1, a cluster is two hardware disk blocks, you will need 2+1 = 3 reads, a penalty of 50%:

OS   |--- cluster  12 ---|--- cluster  13 ---|--- cluster  14...

     |                   |                   |

HDD  --|----|----|----|-a--|--b-|-c--|-d--|-e--|----|---        BAD

     |                   |                   |

HDD  |----|----|----|----|-a--|--b-|-c--|-d--|----|----|---     GOOD

Above, a cluster is 4 hardware blocks (ratio 4:1) of 2 sectors each. Aligning on "even" sectors means that to read a cluster those 8 sector reads translate to 4 block reads. Aligning on odd sectors means that the same 8 sector reads require 4+1 = 5 block reads, a performance penalty of 25% (you add one read every four).

If you have a misaligned disk with 4:1 ratio, aligning it will make it 20% faster (you save one read every 5).

To make a partition "aligned", you either move/set its offset from the beginning of the disk to the appropriate multiple of 512b-sectors, or (depending on the tool) you can insert a small partition at the beginning of the disk, with such a size that the next partition starts exactly on a disk-sector boundary. In this second case, while in theory you need at most N-1 sectors, i.e. very few kilobytes, in practice you'll probably need to waste some hundred of kilobytes, possibly whole megabytes, in order to squeeze the most performances out of your multi-gigabyte hard drive.

(You could probably recover that space, and much more, by properly choosing the OS cluster size).

Drives are nearly always divided into logical sectors of 512 bytes, other sizes are possible but are rarely used due to compatibility issues. With older hard drives these were seperate sectors that could be written individually.

Until the mid 2000s partitions were traditionally aligned to "cylinder" boundries. For historical reasons a "cylinder" was normally 63 sectors. Sector 0 contains the boot sector and parition table. Later sectors in cylinder 0 sometimes contined additional information for the bootloader. The first partition typically began at the start of cylinder 1.

Most filesystems group sectors into larger blocks (sometimes called "clusters"). These are commonly 4KiB in size.

At some point drive vendors reliased it would be more efficient if they also used 4K physical sectors but for compatibility reasons they kept the logical sector size at 512 bytes. If the host reads or writes the whole physical sector at once things are fast. If the reads part of it things are still pretty fast as the drive can just discard the unwanted data. However if the host writes only part of a physical sector the drive must read the physical sector, combine the data read with the data from the host and then rewrite the modified sector. That means waiting for the drive to rotate into position twice rather than once.

This works well if the 4K clusters of the filesystem are aligned to the 4K physical sectors of the drive. Unfortunately the traditional way of partitioning drives means the first partition is basically gauranteed to be misaligned and later partitions had only a 1 in 8 chance of being aligned. Vendors of advanced-format drives therefore had to rush out tools to help people re-align their paritions.

Similar considerations can apply with raid arrays and SSDs. While a raid stripe is likely much larger than a single filesystem cluster some filesystems may have regions or similar that are aligned on power of two boundries.

Current normal practice is to align paritions to 1MiB boundries which is a big enough power of two to be a multiple of all common block sizes.

Most likely they are referring to the new Advanced Format hard drives.

Alignment article here

http://consumer.media.seagate.com/2010/03/the-digital-den/4k-sector-hard-drive-primer/

another one here
http://notepad.patheticcockroach.com/900/dealing-with-wd-advanced-format-hard-drives-on-linux-windows-and-mac-os-part-1/

Dunno if this is helpful, but my understanding was that partition alignment is when you align a given partition with an underlying RAID stripe units.

Apparently, performance may suck when you use a hardware-based RAID or software-based; problems could arise if the starting location of the partition is not aligned with a stripe unit boundary in the disk partition that is created on the RAID.

Depending on the factoring for creating volume clusters, a volume cluster may be created over a stripe unit boundary instead of next to the stripe unit boundary. This behavior could cause a misaligned partition.

I may be way off and this could have nothing to do with RAID ;)