3 ms·

Typical kernels don’t consider rotational latency at all because seek latency is so much more important. Besides, the disk layout isn’t really available to the

Typical kernels don’t consider rotational latency at all because seek latency is so much more important. Besides, the disk layout isn’t really available to the OS anyway, what the OS sees is an abstraction managed by the drive firmware.

namibj 6y ago
Which is almost always a linear mapping going from the outside first. To be fair, that doesn't include rotational latency, but still, the abstraction isn't as abstract as you make it sound.
- tinus_hn 6y ago
  How does that tell you how many sectors are in one track or how many heads are there? Presenting the drive that consists of sectors in tracks on platters as if it is a very long string of sectors, how more abstract can you get? And that’s ignoring reallocated sectors and shingled recording shenanigans.
  - namibj 6y ago
    I'd not be surprised if they since switched to using a true spiral. And the head count is one assembly per disk-surface for almost all devices. So 2 per disk for HDDs. Yes, reallocated sectors aren't accounted for, but they should be so rare as to not matter outside of hard realtime applications, which shouldn't be using such corner-cutting devices anyways. That spiral assumption is due to the servo tracks they need and that the inter-sector gap only has to be sized to account for how fast they can switch the write head from idle to spewing bits, so they have incentive to make it smaller than what they'd likely want the head to be able to jump when continuously streaming data. Multiple platters would likely just mean that random writes with suitable alignment cost the same until you reach the effective platter count, as the sectors that fly by at the same time should be sequential. SSDs on the other hand use some complicated LSM trees or similar datastructures.
Someone 6y ago
That’s why, back in the day, some people carefully placed often-accessed data in the middle of the disk. I think that’s a long lost art, but it still might be done on mainframes (on the really old ones, files were mostly pre-allocated, with individual items stored in a partitioned data set (https://en.wikipedia.org/wiki/Data_set_(IBM_mainframe)#Partitioned_data_set https://en.wikipedia.org/wiki/Data_set_(IBM_mainframe)#Parti...), so you could have some control where individual ‘files’ in a ‘directory’ got stored. Nowadays, you would have to partition a disk to do that) I don’t think it has been cost effective to even think of this kind of black magic for decades, though.

namibj 6y ago

Which is almost always a linear mapping going from the outside first. To be fair, that doesn't include rotational latency, but still, the abstraction isn't as abstract as you make it sound.

tinus_hn 6y ago
How does that tell you how many sectors are in one track or how many heads are there? Presenting the drive that consists of sectors in tracks on platters as if it is a very long string of sectors, how more abstract can you get? And that’s ignoring reallocated sectors and shingled recording shenanigans.
- namibj 6y ago
  I'd not be surprised if they since switched to using a true spiral. And the head count is one assembly per disk-surface for almost all devices. So 2 per disk for HDDs. Yes, reallocated sectors aren't accounted for, but they should be so rare as to not matter outside of hard realtime applications, which shouldn't be using such corner-cutting devices anyways. That spiral assumption is due to the servo tracks they need and that the inter-sector gap only has to be sized to account for how fast they can switch the write head from idle to spewing bits, so they have incentive to make it smaller than what they'd likely want the head to be able to jump when continuously streaming data. Multiple platters would likely just mean that random writes with suitable alignment cost the same until you reach the effective platter count, as the sectors that fly by at the same time should be sequential. SSDs on the other hand use some complicated LSM trees or similar datastructures.

Someone 6y ago

That’s why, back in the day, some people carefully placed often-accessed data in the middle of the disk. I think that’s a long lost art, but it still might be done on mainframes (on the really old ones, files were mostly pre-allocated, with individual items stored in a partitioned data set (https://en.wikipedia.org/wiki/Data_set_(IBM_mainframe)#Partitioned_data_set https://en.wikipedia.org/wiki/Data_set_(IBM_mainframe)#Parti...), so you could have some control where individual ‘files’ in a ‘directory’ got stored. Nowadays, you would have to partition a disk to do that) I don’t think it has been cost effective to even think of this kind of black magic for decades, though.