What's the unit of partitions of hard disks?
Clash Royale CLAN TAG#URR8PPP
I know the unit in the partition table is sector. But is it the size of physical sector size or logical sector size?
When the logical sector size is different with physical sector size, how does linux kernel and partition tools deal with the partition size since numbers in partition table is always recorded as number od sectors.
linux hard-disk
asked Dec 18 at 6:12
炸鱼薯条德里克
399114
add a comment |
I know the unit in the partition table is sector. But is it the size of physical sector size or logical sector size?
When the logical sector size is different with physical sector size, how does linux kernel and partition tools deal with the partition size since numbers in partition table is always recorded as number od sectors.
linux hard-disk
asked Dec 18 at 6:12
炸鱼薯条德里克
399114
add a comment |
I know the unit in the partition table is sector. But is it the size of physical sector size or logical sector size?
When the logical sector size is different with physical sector size, how does linux kernel and partition tools deal with the partition size since numbers in partition table is always recorded as number od sectors.
linux hard-disk
asked Dec 18 at 6:12
炸鱼薯条德里克
399114
I know the unit in the partition table is sector. But is it the size of physical sector size or logical sector size?
When the logical sector size is different with physical sector size, how does linux kernel and partition tools deal with the partition size since numbers in partition table is always recorded as number od sectors.
linux hard-disk
linux hard-disk
asked Dec 18 at 6:12
炸鱼薯条德里克
399114
asked Dec 18 at 6:12
炸鱼薯条德里克
399114
asked Dec 18 at 6:12
炸鱼薯条德里克
399114
asked Dec 18 at 6:12
炸鱼薯条德里克
399114
asked Dec 18 at 6:12
炸鱼薯条德里克
399114
399114
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
As you can see e.g. on Wikipedia, the entries in the GPT are LBA's (Logical Block Addresses). These are addresses based on the logical sector size.
When harddisks started to have a different (larger) physical sector size, the vendors kept the old physical sector size as logical sector size, to help old systems use the new harddisks. This means the harddisk firmware contains code that can deal with logical sector reads and writes: For a read, it will read the correct (larger) physical sector and return only part of it. For a write, it will first read the (larger) physical sector, then modify part of it, and the move it back.
This is inefficient unless reads and writes happen at LBAs that correspond to the start of a physical sector, and with lengths that are multiple of physical sectors.
So the way the kernel deals with large physical sector sizes is that it tries only to use these kind of reads and writes. For this to work, the partitions must be aligned correctly (on boundaries of physical sectors). Usually, partitioning programs will ensure that this is the case, and print a warning if you try to use them in a way where it isn't.
The kernel doesn't have to do that; it would work even without doing it, but it would be less efficient.
Edit
Can userland apps just read the logical sector size through /sys and read the partition table then multiply them together to tell the user how big a partition is?
Yes, userland apps like fdisk do exactly that (though I think the physical and logical sector size is in /proc, not in /sys, but I'd have to look this up).
When the kernel operates filesystem, it doesn't need to know the size of underlying storage, just the size of filesystem structure by reading the metadata of the filesystem, is that right?
It's a bit more difficult: The basic kernel unit is a "page" (the MMU unit), and the basic unit of a particular filesystem is a "block" (sometimes multiple pages). The kernel just needs to know how this relates to the logical block size of the underlying storage, because that's needed to calculate the LBAs.
But kernel needs to know the start and size of a partition when userland access raw partition device like /dev/sda2, isn't that true?
Yes. That's why it reads the partition table before it creates entries like /dev/sda2.
When kernel do this, it needs to know the unit of numbers recorded in partition table is logical sector size, not physical sector size, right?
Yes.
answered Dec 18 at 7:14
dirkt
16.6k21335
Can userland apps just read the logical sector size through /sys and read the partition table then multiply them together to tell the user how big a partition is? When the kernel operates filesystem, it doesn't need to know the size of underlying storage, just the size of filesystem structure by reading the metadata of the filesystem, is that right?
– 炸鱼薯条德里克
Dec 18 at 7:48
But kernel needs to know the start and size of a partition when userland access raw partition device like/dev/sda2, isn't that true? When kernel do this, it needs to know the unit of numbers recorded in partition table is logical sector size, not physical sector size, right?
– 炸鱼薯条德里克
Dec 18 at 7:54
Strictly speaking, the kernel only needs to know the logical sector size (= the size of the smallest individually addressable unit of disk space), but it is useful for the kernel to know the physical sector size too: some storages (multi-TB HDDs, enterprise SAN storage systems) use larger physical sector size internally, and arranging the disk I/O operations to conform to the physical sector size usually results in better performance than ignoring the difference.
– telcoM
Dec 18 at 9:42
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%2f489620%2fwhats-the-unit-of-partitions-of-hard-disks%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
As you can see e.g. on Wikipedia, the entries in the GPT are LBA's (Logical Block Addresses). These are addresses based on the logical sector size.
When harddisks started to have a different (larger) physical sector size, the vendors kept the old physical sector size as logical sector size, to help old systems use the new harddisks. This means the harddisk firmware contains code that can deal with logical sector reads and writes: For a read, it will read the correct (larger) physical sector and return only part of it. For a write, it will first read the (larger) physical sector, then modify part of it, and the move it back.
This is inefficient unless reads and writes happen at LBAs that correspond to the start of a physical sector, and with lengths that are multiple of physical sectors.
So the way the kernel deals with large physical sector sizes is that it tries only to use these kind of reads and writes. For this to work, the partitions must be aligned correctly (on boundaries of physical sectors). Usually, partitioning programs will ensure that this is the case, and print a warning if you try to use them in a way where it isn't.
The kernel doesn't have to do that; it would work even without doing it, but it would be less efficient.
Edit
Can userland apps just read the logical sector size through /sys and read the partition table then multiply them together to tell the user how big a partition is?
Yes, userland apps like fdisk do exactly that (though I think the physical and logical sector size is in /proc, not in /sys, but I'd have to look this up).
When the kernel operates filesystem, it doesn't need to know the size of underlying storage, just the size of filesystem structure by reading the metadata of the filesystem, is that right?
It's a bit more difficult: The basic kernel unit is a "page" (the MMU unit), and the basic unit of a particular filesystem is a "block" (sometimes multiple pages). The kernel just needs to know how this relates to the logical block size of the underlying storage, because that's needed to calculate the LBAs.
But kernel needs to know the start and size of a partition when userland access raw partition device like /dev/sda2, isn't that true?
Yes. That's why it reads the partition table before it creates entries like /dev/sda2.
When kernel do this, it needs to know the unit of numbers recorded in partition table is logical sector size, not physical sector size, right?
Yes.
answered Dec 18 at 7:14
dirkt
16.6k21335
Can userland apps just read the logical sector size through /sys and read the partition table then multiply them together to tell the user how big a partition is? When the kernel operates filesystem, it doesn't need to know the size of underlying storage, just the size of filesystem structure by reading the metadata of the filesystem, is that right?
– 炸鱼薯条德里克
Dec 18 at 7:48
But kernel needs to know the start and size of a partition when userland access raw partition device like/dev/sda2, isn't that true? When kernel do this, it needs to know the unit of numbers recorded in partition table is logical sector size, not physical sector size, right?
– 炸鱼薯条德里克
Dec 18 at 7:54
Strictly speaking, the kernel only needs to know the logical sector size (= the size of the smallest individually addressable unit of disk space), but it is useful for the kernel to know the physical sector size too: some storages (multi-TB HDDs, enterprise SAN storage systems) use larger physical sector size internally, and arranging the disk I/O operations to conform to the physical sector size usually results in better performance than ignoring the difference.
– telcoM
Dec 18 at 9:42
add a comment |
As you can see e.g. on Wikipedia, the entries in the GPT are LBA's (Logical Block Addresses). These are addresses based on the logical sector size.
When harddisks started to have a different (larger) physical sector size, the vendors kept the old physical sector size as logical sector size, to help old systems use the new harddisks. This means the harddisk firmware contains code that can deal with logical sector reads and writes: For a read, it will read the correct (larger) physical sector and return only part of it. For a write, it will first read the (larger) physical sector, then modify part of it, and the move it back.
This is inefficient unless reads and writes happen at LBAs that correspond to the start of a physical sector, and with lengths that are multiple of physical sectors.
So the way the kernel deals with large physical sector sizes is that it tries only to use these kind of reads and writes. For this to work, the partitions must be aligned correctly (on boundaries of physical sectors). Usually, partitioning programs will ensure that this is the case, and print a warning if you try to use them in a way where it isn't.
The kernel doesn't have to do that; it would work even without doing it, but it would be less efficient.
Edit
Can userland apps just read the logical sector size through /sys and read the partition table then multiply them together to tell the user how big a partition is?
Yes, userland apps like fdisk do exactly that (though I think the physical and logical sector size is in /proc, not in /sys, but I'd have to look this up).
When the kernel operates filesystem, it doesn't need to know the size of underlying storage, just the size of filesystem structure by reading the metadata of the filesystem, is that right?
It's a bit more difficult: The basic kernel unit is a "page" (the MMU unit), and the basic unit of a particular filesystem is a "block" (sometimes multiple pages). The kernel just needs to know how this relates to the logical block size of the underlying storage, because that's needed to calculate the LBAs.
But kernel needs to know the start and size of a partition when userland access raw partition device like /dev/sda2, isn't that true?
Yes. That's why it reads the partition table before it creates entries like /dev/sda2.
When kernel do this, it needs to know the unit of numbers recorded in partition table is logical sector size, not physical sector size, right?
Yes.
answered Dec 18 at 7:14
dirkt
16.6k21335
Can userland apps just read the logical sector size through /sys and read the partition table then multiply them together to tell the user how big a partition is? When the kernel operates filesystem, it doesn't need to know the size of underlying storage, just the size of filesystem structure by reading the metadata of the filesystem, is that right?
– 炸鱼薯条德里克
Dec 18 at 7:48
But kernel needs to know the start and size of a partition when userland access raw partition device like/dev/sda2, isn't that true? When kernel do this, it needs to know the unit of numbers recorded in partition table is logical sector size, not physical sector size, right?
– 炸鱼薯条德里克
Dec 18 at 7:54
Strictly speaking, the kernel only needs to know the logical sector size (= the size of the smallest individually addressable unit of disk space), but it is useful for the kernel to know the physical sector size too: some storages (multi-TB HDDs, enterprise SAN storage systems) use larger physical sector size internally, and arranging the disk I/O operations to conform to the physical sector size usually results in better performance than ignoring the difference.
– telcoM
Dec 18 at 9:42
add a comment |
As you can see e.g. on Wikipedia, the entries in the GPT are LBA's (Logical Block Addresses). These are addresses based on the logical sector size.
When harddisks started to have a different (larger) physical sector size, the vendors kept the old physical sector size as logical sector size, to help old systems use the new harddisks. This means the harddisk firmware contains code that can deal with logical sector reads and writes: For a read, it will read the correct (larger) physical sector and return only part of it. For a write, it will first read the (larger) physical sector, then modify part of it, and the move it back.
This is inefficient unless reads and writes happen at LBAs that correspond to the start of a physical sector, and with lengths that are multiple of physical sectors.
So the way the kernel deals with large physical sector sizes is that it tries only to use these kind of reads and writes. For this to work, the partitions must be aligned correctly (on boundaries of physical sectors). Usually, partitioning programs will ensure that this is the case, and print a warning if you try to use them in a way where it isn't.
The kernel doesn't have to do that; it would work even without doing it, but it would be less efficient.
Edit
Can userland apps just read the logical sector size through /sys and read the partition table then multiply them together to tell the user how big a partition is?
Yes, userland apps like fdisk do exactly that (though I think the physical and logical sector size is in /proc, not in /sys, but I'd have to look this up).
When the kernel operates filesystem, it doesn't need to know the size of underlying storage, just the size of filesystem structure by reading the metadata of the filesystem, is that right?
It's a bit more difficult: The basic kernel unit is a "page" (the MMU unit), and the basic unit of a particular filesystem is a "block" (sometimes multiple pages). The kernel just needs to know how this relates to the logical block size of the underlying storage, because that's needed to calculate the LBAs.
But kernel needs to know the start and size of a partition when userland access raw partition device like /dev/sda2, isn't that true?
Yes. That's why it reads the partition table before it creates entries like /dev/sda2.
When kernel do this, it needs to know the unit of numbers recorded in partition table is logical sector size, not physical sector size, right?
Yes.
answered Dec 18 at 7:14
dirkt
16.6k21335
As you can see e.g. on Wikipedia, the entries in the GPT are LBA's (Logical Block Addresses). These are addresses based on the logical sector size.
When harddisks started to have a different (larger) physical sector size, the vendors kept the old physical sector size as logical sector size, to help old systems use the new harddisks. This means the harddisk firmware contains code that can deal with logical sector reads and writes: For a read, it will read the correct (larger) physical sector and return only part of it. For a write, it will first read the (larger) physical sector, then modify part of it, and the move it back.
This is inefficient unless reads and writes happen at LBAs that correspond to the start of a physical sector, and with lengths that are multiple of physical sectors.
So the way the kernel deals with large physical sector sizes is that it tries only to use these kind of reads and writes. For this to work, the partitions must be aligned correctly (on boundaries of physical sectors). Usually, partitioning programs will ensure that this is the case, and print a warning if you try to use them in a way where it isn't.
The kernel doesn't have to do that; it would work even without doing it, but it would be less efficient.
Edit
Can userland apps just read the logical sector size through /sys and read the partition table then multiply them together to tell the user how big a partition is?
Yes, userland apps like fdisk do exactly that (though I think the physical and logical sector size is in /proc, not in /sys, but I'd have to look this up).
When the kernel operates filesystem, it doesn't need to know the size of underlying storage, just the size of filesystem structure by reading the metadata of the filesystem, is that right?
It's a bit more difficult: The basic kernel unit is a "page" (the MMU unit), and the basic unit of a particular filesystem is a "block" (sometimes multiple pages). The kernel just needs to know how this relates to the logical block size of the underlying storage, because that's needed to calculate the LBAs.
But kernel needs to know the start and size of a partition when userland access raw partition device like /dev/sda2, isn't that true?
Yes. That's why it reads the partition table before it creates entries like /dev/sda2.
When kernel do this, it needs to know the unit of numbers recorded in partition table is logical sector size, not physical sector size, right?
Yes.
answered Dec 18 at 7:14
dirkt
16.6k21335
edited Dec 18 at 8:23
answered Dec 18 at 7:14
dirkt
16.6k21335
answered Dec 18 at 7:14
dirkt
16.6k21335
answered Dec 18 at 7:14
dirkt
16.6k21335
16.6k21335
Can userland apps just read the logical sector size through /sys and read the partition table then multiply them together to tell the user how big a partition is? When the kernel operates filesystem, it doesn't need to know the size of underlying storage, just the size of filesystem structure by reading the metadata of the filesystem, is that right?
– 炸鱼薯条德里克
Dec 18 at 7:48
But kernel needs to know the start and size of a partition when userland access raw partition device like/dev/sda2, isn't that true? When kernel do this, it needs to know the unit of numbers recorded in partition table is logical sector size, not physical sector size, right?
– 炸鱼薯条德里克
Dec 18 at 7:54
Strictly speaking, the kernel only needs to know the logical sector size (= the size of the smallest individually addressable unit of disk space), but it is useful for the kernel to know the physical sector size too: some storages (multi-TB HDDs, enterprise SAN storage systems) use larger physical sector size internally, and arranging the disk I/O operations to conform to the physical sector size usually results in better performance than ignoring the difference.
– telcoM
Dec 18 at 9:42
add a comment |
Can userland apps just read the logical sector size through /sys and read the partition table then multiply them together to tell the user how big a partition is? When the kernel operates filesystem, it doesn't need to know the size of underlying storage, just the size of filesystem structure by reading the metadata of the filesystem, is that right?
– 炸鱼薯条德里克
Dec 18 at 7:48
But kernel needs to know the start and size of a partition when userland access raw partition device like/dev/sda2, isn't that true? When kernel do this, it needs to know the unit of numbers recorded in partition table is logical sector size, not physical sector size, right?
– 炸鱼薯条德里克
Dec 18 at 7:54
Strictly speaking, the kernel only needs to know the logical sector size (= the size of the smallest individually addressable unit of disk space), but it is useful for the kernel to know the physical sector size too: some storages (multi-TB HDDs, enterprise SAN storage systems) use larger physical sector size internally, and arranging the disk I/O operations to conform to the physical sector size usually results in better performance than ignoring the difference.
– telcoM
Dec 18 at 9:42
Can userland apps just read the logical sector size through /sys and read the partition table then multiply them together to tell the user how big a partition is? When the kernel operates filesystem, it doesn't need to know the size of underlying storage, just the size of filesystem structure by reading the metadata of the filesystem, is that right?
– 炸鱼薯条德里克
Dec 18 at 7:48
Can userland apps just read the logical sector size through /sys and read the partition table then multiply them together to tell the user how big a partition is? When the kernel operates filesystem, it doesn't need to know the size of underlying storage, just the size of filesystem structure by reading the metadata of the filesystem, is that right?
– 炸鱼薯条德里克
Dec 18 at 7:48
But kernel needs to know the start and size of a partition when userland access raw partition device like
/dev/sda2, isn't that true? When kernel do this, it needs to know the unit of numbers recorded in partition table is logical sector size, not physical sector size, right?– 炸鱼薯条德里克
Dec 18 at 7:54
But kernel needs to know the start and size of a partition when userland access raw partition device like
/dev/sda2, isn't that true? When kernel do this, it needs to know the unit of numbers recorded in partition table is logical sector size, not physical sector size, right?– 炸鱼薯条德里克
Dec 18 at 7:54
Strictly speaking, the kernel only needs to know the logical sector size (= the size of the smallest individually addressable unit of disk space), but it is useful for the kernel to know the physical sector size too: some storages (multi-TB HDDs, enterprise SAN storage systems) use larger physical sector size internally, and arranging the disk I/O operations to conform to the physical sector size usually results in better performance than ignoring the difference.
– telcoM
Dec 18 at 9:42
Strictly speaking, the kernel only needs to know the logical sector size (= the size of the smallest individually addressable unit of disk space), but it is useful for the kernel to know the physical sector size too: some storages (multi-TB HDDs, enterprise SAN storage systems) use larger physical sector size internally, and arranging the disk I/O operations to conform to the physical sector size usually results in better performance than ignoring the difference.
– telcoM
Dec 18 at 9:42
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%2f489620%2fwhats-the-unit-of-partitions-of-hard-disks%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