Can the logical sector size be set on newer HDD/SSDs?
I believe this is the same question as Optimizing logical sector size for physical sector size 4096 HDD but that question never got an accepted answer and the existing answers dance around the core question.
If I have an advanced format HDD/SSD that I know has a physical sector size of 4K, AND I know that all the hardware/software on my system can handle a minimum I/O size of 4K, AND I'm OK with the marginal loss of free space for files smaller than 4K, THEN is there a way for me to set it up so that all components of the system view that device has having both a logical and physical sector size of 4K?
I expect a solid answer including the following information:
What information does the disk reports to the kernel?
Does the kernel unconditionally and truthfully reports that info via
/sys
or whether it can be made to conditionally adjust the values?Whether components other than the kernel might directly interact
with the hardware and discover this information.
linux-kernel hard-disk block-device
add a comment |
I believe this is the same question as Optimizing logical sector size for physical sector size 4096 HDD but that question never got an accepted answer and the existing answers dance around the core question.
If I have an advanced format HDD/SSD that I know has a physical sector size of 4K, AND I know that all the hardware/software on my system can handle a minimum I/O size of 4K, AND I'm OK with the marginal loss of free space for files smaller than 4K, THEN is there a way for me to set it up so that all components of the system view that device has having both a logical and physical sector size of 4K?
I expect a solid answer including the following information:
What information does the disk reports to the kernel?
Does the kernel unconditionally and truthfully reports that info via
/sys
or whether it can be made to conditionally adjust the values?Whether components other than the kernel might directly interact
with the hardware and discover this information.
linux-kernel hard-disk block-device
1
You made a long list of conditions for you to accept an answer. Now please describe what problem are you actually trying to solve, and what are your criteria for deciding whether said problem is solved on not in a given situation. In particular, do you have any numbers to back up your claims?
– Satō Katsura
May 24 '17 at 4:18
The problem is of course alignment, which I know the canonical solution for. But the canonical solution is hard to verify that it was applied correctly. Checking alignment when you have several disks in RAID, over which you have LUKS encryption, over which you have a filesystem can be tedious if not hard. A simple way to avoid that is to ensure there is only one option: 4k.
– Huckle
May 24 '17 at 20:16
add a comment |
I believe this is the same question as Optimizing logical sector size for physical sector size 4096 HDD but that question never got an accepted answer and the existing answers dance around the core question.
If I have an advanced format HDD/SSD that I know has a physical sector size of 4K, AND I know that all the hardware/software on my system can handle a minimum I/O size of 4K, AND I'm OK with the marginal loss of free space for files smaller than 4K, THEN is there a way for me to set it up so that all components of the system view that device has having both a logical and physical sector size of 4K?
I expect a solid answer including the following information:
What information does the disk reports to the kernel?
Does the kernel unconditionally and truthfully reports that info via
/sys
or whether it can be made to conditionally adjust the values?Whether components other than the kernel might directly interact
with the hardware and discover this information.
linux-kernel hard-disk block-device
I believe this is the same question as Optimizing logical sector size for physical sector size 4096 HDD but that question never got an accepted answer and the existing answers dance around the core question.
If I have an advanced format HDD/SSD that I know has a physical sector size of 4K, AND I know that all the hardware/software on my system can handle a minimum I/O size of 4K, AND I'm OK with the marginal loss of free space for files smaller than 4K, THEN is there a way for me to set it up so that all components of the system view that device has having both a logical and physical sector size of 4K?
I expect a solid answer including the following information:
What information does the disk reports to the kernel?
Does the kernel unconditionally and truthfully reports that info via
/sys
or whether it can be made to conditionally adjust the values?Whether components other than the kernel might directly interact
with the hardware and discover this information.
linux-kernel hard-disk block-device
linux-kernel hard-disk block-device
edited Dec 19 '18 at 11:13
炸鱼薯条德里克
404114
404114
asked May 24 '17 at 2:05
Huckle
349417
349417
1
You made a long list of conditions for you to accept an answer. Now please describe what problem are you actually trying to solve, and what are your criteria for deciding whether said problem is solved on not in a given situation. In particular, do you have any numbers to back up your claims?
– Satō Katsura
May 24 '17 at 4:18
The problem is of course alignment, which I know the canonical solution for. But the canonical solution is hard to verify that it was applied correctly. Checking alignment when you have several disks in RAID, over which you have LUKS encryption, over which you have a filesystem can be tedious if not hard. A simple way to avoid that is to ensure there is only one option: 4k.
– Huckle
May 24 '17 at 20:16
add a comment |
1
You made a long list of conditions for you to accept an answer. Now please describe what problem are you actually trying to solve, and what are your criteria for deciding whether said problem is solved on not in a given situation. In particular, do you have any numbers to back up your claims?
– Satō Katsura
May 24 '17 at 4:18
The problem is of course alignment, which I know the canonical solution for. But the canonical solution is hard to verify that it was applied correctly. Checking alignment when you have several disks in RAID, over which you have LUKS encryption, over which you have a filesystem can be tedious if not hard. A simple way to avoid that is to ensure there is only one option: 4k.
– Huckle
May 24 '17 at 20:16
1
1
You made a long list of conditions for you to accept an answer. Now please describe what problem are you actually trying to solve, and what are your criteria for deciding whether said problem is solved on not in a given situation. In particular, do you have any numbers to back up your claims?
– Satō Katsura
May 24 '17 at 4:18
You made a long list of conditions for you to accept an answer. Now please describe what problem are you actually trying to solve, and what are your criteria for deciding whether said problem is solved on not in a given situation. In particular, do you have any numbers to back up your claims?
– Satō Katsura
May 24 '17 at 4:18
The problem is of course alignment, which I know the canonical solution for. But the canonical solution is hard to verify that it was applied correctly. Checking alignment when you have several disks in RAID, over which you have LUKS encryption, over which you have a filesystem can be tedious if not hard. A simple way to avoid that is to ensure there is only one option: 4k.
– Huckle
May 24 '17 at 20:16
The problem is of course alignment, which I know the canonical solution for. But the canonical solution is hard to verify that it was applied correctly. Checking alignment when you have several disks in RAID, over which you have LUKS encryption, over which you have a filesystem can be tedious if not hard. A simple way to avoid that is to ensure there is only one option: 4k.
– Huckle
May 24 '17 at 20:16
add a comment |
2 Answers
2
active
oldest
votes
It's not the kernel you need to patch for #1, it's the hard drive you will have to tell to both report and use a logical sector size of 4k.
On the other hand, if (as you say) all your software is prepared for a logical sector size of 4k, what difference does the sector size make? If all your reads and writes are multiples of 4k and are neatly aligned, what advantage do you gain from issuing a read command to the drive reading
- 25 blocks starting from block 155, vs.
- 200 blocks starting from block 1240?
It's about ease of verification. It's tedious to check alignment and block sizes for many layers of stack blocked devices and filesystems to make sure they are all aligned and of optimal size. If you can eliminate all the options at the source you've reduced the chances of something going wrong.
– Huckle
May 24 '17 at 20:19
add a comment |
I believe that some WD hard drives have a jumper you can set to switch the logical sector size to 4k, but there is really no need to do so since all recent software understands that the physical sector size is 4k and with automatically handle the correct alignment. For this reason, they may have phased out the jumper setting.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
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: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
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%2funix.stackexchange.com%2fquestions%2f366876%2fcan-the-logical-sector-size-be-set-on-newer-hdd-ssds%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
It's not the kernel you need to patch for #1, it's the hard drive you will have to tell to both report and use a logical sector size of 4k.
On the other hand, if (as you say) all your software is prepared for a logical sector size of 4k, what difference does the sector size make? If all your reads and writes are multiples of 4k and are neatly aligned, what advantage do you gain from issuing a read command to the drive reading
- 25 blocks starting from block 155, vs.
- 200 blocks starting from block 1240?
It's about ease of verification. It's tedious to check alignment and block sizes for many layers of stack blocked devices and filesystems to make sure they are all aligned and of optimal size. If you can eliminate all the options at the source you've reduced the chances of something going wrong.
– Huckle
May 24 '17 at 20:19
add a comment |
It's not the kernel you need to patch for #1, it's the hard drive you will have to tell to both report and use a logical sector size of 4k.
On the other hand, if (as you say) all your software is prepared for a logical sector size of 4k, what difference does the sector size make? If all your reads and writes are multiples of 4k and are neatly aligned, what advantage do you gain from issuing a read command to the drive reading
- 25 blocks starting from block 155, vs.
- 200 blocks starting from block 1240?
It's about ease of verification. It's tedious to check alignment and block sizes for many layers of stack blocked devices and filesystems to make sure they are all aligned and of optimal size. If you can eliminate all the options at the source you've reduced the chances of something going wrong.
– Huckle
May 24 '17 at 20:19
add a comment |
It's not the kernel you need to patch for #1, it's the hard drive you will have to tell to both report and use a logical sector size of 4k.
On the other hand, if (as you say) all your software is prepared for a logical sector size of 4k, what difference does the sector size make? If all your reads and writes are multiples of 4k and are neatly aligned, what advantage do you gain from issuing a read command to the drive reading
- 25 blocks starting from block 155, vs.
- 200 blocks starting from block 1240?
It's not the kernel you need to patch for #1, it's the hard drive you will have to tell to both report and use a logical sector size of 4k.
On the other hand, if (as you say) all your software is prepared for a logical sector size of 4k, what difference does the sector size make? If all your reads and writes are multiples of 4k and are neatly aligned, what advantage do you gain from issuing a read command to the drive reading
- 25 blocks starting from block 155, vs.
- 200 blocks starting from block 1240?
edited May 24 '17 at 21:54
answered May 24 '17 at 11:18
Johan Myréen
7,44011524
7,44011524
It's about ease of verification. It's tedious to check alignment and block sizes for many layers of stack blocked devices and filesystems to make sure they are all aligned and of optimal size. If you can eliminate all the options at the source you've reduced the chances of something going wrong.
– Huckle
May 24 '17 at 20:19
add a comment |
It's about ease of verification. It's tedious to check alignment and block sizes for many layers of stack blocked devices and filesystems to make sure they are all aligned and of optimal size. If you can eliminate all the options at the source you've reduced the chances of something going wrong.
– Huckle
May 24 '17 at 20:19
It's about ease of verification. It's tedious to check alignment and block sizes for many layers of stack blocked devices and filesystems to make sure they are all aligned and of optimal size. If you can eliminate all the options at the source you've reduced the chances of something going wrong.
– Huckle
May 24 '17 at 20:19
It's about ease of verification. It's tedious to check alignment and block sizes for many layers of stack blocked devices and filesystems to make sure they are all aligned and of optimal size. If you can eliminate all the options at the source you've reduced the chances of something going wrong.
– Huckle
May 24 '17 at 20:19
add a comment |
I believe that some WD hard drives have a jumper you can set to switch the logical sector size to 4k, but there is really no need to do so since all recent software understands that the physical sector size is 4k and with automatically handle the correct alignment. For this reason, they may have phased out the jumper setting.
add a comment |
I believe that some WD hard drives have a jumper you can set to switch the logical sector size to 4k, but there is really no need to do so since all recent software understands that the physical sector size is 4k and with automatically handle the correct alignment. For this reason, they may have phased out the jumper setting.
add a comment |
I believe that some WD hard drives have a jumper you can set to switch the logical sector size to 4k, but there is really no need to do so since all recent software understands that the physical sector size is 4k and with automatically handle the correct alignment. For this reason, they may have phased out the jumper setting.
I believe that some WD hard drives have a jumper you can set to switch the logical sector size to 4k, but there is really no need to do so since all recent software understands that the physical sector size is 4k and with automatically handle the correct alignment. For this reason, they may have phased out the jumper setting.
answered May 25 '17 at 3:01
psusi
13.5k22439
13.5k22439
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- 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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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%2funix.stackexchange.com%2fquestions%2f366876%2fcan-the-logical-sector-size-be-set-on-newer-hdd-ssds%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
1
You made a long list of conditions for you to accept an answer. Now please describe what problem are you actually trying to solve, and what are your criteria for deciding whether said problem is solved on not in a given situation. In particular, do you have any numbers to back up your claims?
– Satō Katsura
May 24 '17 at 4:18
The problem is of course alignment, which I know the canonical solution for. But the canonical solution is hard to verify that it was applied correctly. Checking alignment when you have several disks in RAID, over which you have LUKS encryption, over which you have a filesystem can be tedious if not hard. A simple way to avoid that is to ensure there is only one option: 4k.
– Huckle
May 24 '17 at 20:16