What does it mean to “align” partitions?
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?
partitioning terminology
add a comment |
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?
partitioning terminology
add a comment |
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?
partitioning terminology
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?
partitioning terminology
partitioning terminology
edited Apr 13 '17 at 12:22
Community♦
1
1
asked Dec 26 '10 at 21:08
81288128
211211
211211
add a comment |
add a comment |
5 Answers
5
active
oldest
votes
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.
Do you have any suggestion on unix.stackexchange.com/questions/248939/…
– AnkurTank
Dec 15 '15 at 13:11
@AnkurTank: No, the question there seems well covered.
– Zan Lynx
Dec 15 '15 at 16:53
Thank you for your attention, only thing left there is how to confirm that partitions are aligned. Because for me parted is still complaining that partitions are not aligned. Moreover I tried using other tool e.g. gdisk, but I am not able to cross compile gdisk for . So I thought if you have any suggestion on how to verify that will help.
– AnkurTank
Dec 16 '15 at 7:00
add a comment |
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).
1
Reads aren't so bad, yes you have to read a bit of extra data but reading three contiguous blocks doesn't cost significantly more time than reading two. The real problem is writes, to write a section that is smaller than the underlying block size requires reading the data, waiting for the disk to spin a full revoloution and then rewriting it.
– plugwash
Dec 5 '16 at 9:16
1
Also there is no need to create extra partitions, there is no rule that all space on a disk has to be paritioned.
– plugwash
Dec 5 '16 at 9:16
add a comment |
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.
add a comment |
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/
add a comment |
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 ;)
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f225936%2fwhat-does-it-mean-to-align-partitions%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
Do you have any suggestion on unix.stackexchange.com/questions/248939/…
– AnkurTank
Dec 15 '15 at 13:11
@AnkurTank: No, the question there seems well covered.
– Zan Lynx
Dec 15 '15 at 16:53
Thank you for your attention, only thing left there is how to confirm that partitions are aligned. Because for me parted is still complaining that partitions are not aligned. Moreover I tried using other tool e.g. gdisk, but I am not able to cross compile gdisk for . So I thought if you have any suggestion on how to verify that will help.
– AnkurTank
Dec 16 '15 at 7:00
add a comment |
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.
Do you have any suggestion on unix.stackexchange.com/questions/248939/…
– AnkurTank
Dec 15 '15 at 13:11
@AnkurTank: No, the question there seems well covered.
– Zan Lynx
Dec 15 '15 at 16:53
Thank you for your attention, only thing left there is how to confirm that partitions are aligned. Because for me parted is still complaining that partitions are not aligned. Moreover I tried using other tool e.g. gdisk, but I am not able to cross compile gdisk for . So I thought if you have any suggestion on how to verify that will help.
– AnkurTank
Dec 16 '15 at 7:00
add a comment |
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.
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.
answered Jan 26 '11 at 22:32
Zan LynxZan Lynx
1,40811116
1,40811116
Do you have any suggestion on unix.stackexchange.com/questions/248939/…
– AnkurTank
Dec 15 '15 at 13:11
@AnkurTank: No, the question there seems well covered.
– Zan Lynx
Dec 15 '15 at 16:53
Thank you for your attention, only thing left there is how to confirm that partitions are aligned. Because for me parted is still complaining that partitions are not aligned. Moreover I tried using other tool e.g. gdisk, but I am not able to cross compile gdisk for . So I thought if you have any suggestion on how to verify that will help.
– AnkurTank
Dec 16 '15 at 7:00
add a comment |
Do you have any suggestion on unix.stackexchange.com/questions/248939/…
– AnkurTank
Dec 15 '15 at 13:11
@AnkurTank: No, the question there seems well covered.
– Zan Lynx
Dec 15 '15 at 16:53
Thank you for your attention, only thing left there is how to confirm that partitions are aligned. Because for me parted is still complaining that partitions are not aligned. Moreover I tried using other tool e.g. gdisk, but I am not able to cross compile gdisk for . So I thought if you have any suggestion on how to verify that will help.
– AnkurTank
Dec 16 '15 at 7:00
Do you have any suggestion on unix.stackexchange.com/questions/248939/…
– AnkurTank
Dec 15 '15 at 13:11
Do you have any suggestion on unix.stackexchange.com/questions/248939/…
– AnkurTank
Dec 15 '15 at 13:11
@AnkurTank: No, the question there seems well covered.
– Zan Lynx
Dec 15 '15 at 16:53
@AnkurTank: No, the question there seems well covered.
– Zan Lynx
Dec 15 '15 at 16:53
Thank you for your attention, only thing left there is how to confirm that partitions are aligned. Because for me parted is still complaining that partitions are not aligned. Moreover I tried using other tool e.g. gdisk, but I am not able to cross compile gdisk for . So I thought if you have any suggestion on how to verify that will help.
– AnkurTank
Dec 16 '15 at 7:00
Thank you for your attention, only thing left there is how to confirm that partitions are aligned. Because for me parted is still complaining that partitions are not aligned. Moreover I tried using other tool e.g. gdisk, but I am not able to cross compile gdisk for . So I thought if you have any suggestion on how to verify that will help.
– AnkurTank
Dec 16 '15 at 7:00
add a comment |
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).
1
Reads aren't so bad, yes you have to read a bit of extra data but reading three contiguous blocks doesn't cost significantly more time than reading two. The real problem is writes, to write a section that is smaller than the underlying block size requires reading the data, waiting for the disk to spin a full revoloution and then rewriting it.
– plugwash
Dec 5 '16 at 9:16
1
Also there is no need to create extra partitions, there is no rule that all space on a disk has to be paritioned.
– plugwash
Dec 5 '16 at 9:16
add a comment |
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).
1
Reads aren't so bad, yes you have to read a bit of extra data but reading three contiguous blocks doesn't cost significantly more time than reading two. The real problem is writes, to write a section that is smaller than the underlying block size requires reading the data, waiting for the disk to spin a full revoloution and then rewriting it.
– plugwash
Dec 5 '16 at 9:16
1
Also there is no need to create extra partitions, there is no rule that all space on a disk has to be paritioned.
– plugwash
Dec 5 '16 at 9:16
add a comment |
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).
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).
edited Dec 5 '16 at 19:19
answered Jun 7 '16 at 17:50
LSerniLSerni
6,98112038
6,98112038
1
Reads aren't so bad, yes you have to read a bit of extra data but reading three contiguous blocks doesn't cost significantly more time than reading two. The real problem is writes, to write a section that is smaller than the underlying block size requires reading the data, waiting for the disk to spin a full revoloution and then rewriting it.
– plugwash
Dec 5 '16 at 9:16
1
Also there is no need to create extra partitions, there is no rule that all space on a disk has to be paritioned.
– plugwash
Dec 5 '16 at 9:16
add a comment |
1
Reads aren't so bad, yes you have to read a bit of extra data but reading three contiguous blocks doesn't cost significantly more time than reading two. The real problem is writes, to write a section that is smaller than the underlying block size requires reading the data, waiting for the disk to spin a full revoloution and then rewriting it.
– plugwash
Dec 5 '16 at 9:16
1
Also there is no need to create extra partitions, there is no rule that all space on a disk has to be paritioned.
– plugwash
Dec 5 '16 at 9:16
1
1
Reads aren't so bad, yes you have to read a bit of extra data but reading three contiguous blocks doesn't cost significantly more time than reading two. The real problem is writes, to write a section that is smaller than the underlying block size requires reading the data, waiting for the disk to spin a full revoloution and then rewriting it.
– plugwash
Dec 5 '16 at 9:16
Reads aren't so bad, yes you have to read a bit of extra data but reading three contiguous blocks doesn't cost significantly more time than reading two. The real problem is writes, to write a section that is smaller than the underlying block size requires reading the data, waiting for the disk to spin a full revoloution and then rewriting it.
– plugwash
Dec 5 '16 at 9:16
1
1
Also there is no need to create extra partitions, there is no rule that all space on a disk has to be paritioned.
– plugwash
Dec 5 '16 at 9:16
Also there is no need to create extra partitions, there is no rule that all space on a disk has to be paritioned.
– plugwash
Dec 5 '16 at 9:16
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
edited Feb 15 at 15:33
answered Dec 5 '16 at 9:34
plugwashplugwash
4,3042917
4,3042917
add a comment |
add a comment |
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/
add a comment |
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/
add a comment |
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/
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/
answered Dec 26 '10 at 22:26
MoabMoab
51.5k1494161
51.5k1494161
add a comment |
add a comment |
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 ;)
add a comment |
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 ;)
add a comment |
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 ;)
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 ;)
answered Dec 26 '10 at 21:41
LuxuryModeLuxuryMode
1408
1408
add a comment |
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f225936%2fwhat-does-it-mean-to-align-partitions%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown