Why does the disk optimizer put boot files at low-numbered sectors?
Raymond Chen
When the disk optimizer rearranges data on the disk, one of the things it does is put boot files at low-numbered sectors. Why is that? Is it just for mathematical convenience? Why not put them at the highest-numbered sectors, so they stay out of the way of regular data?
Rotational media number their tracks and sectors from the outside in. The lowest-numbered tracks and sectors are at the outer rim, and the highest-numbered tracks and sectors are near the center. And it’s that geometry that the disk optimizer takes advantage of.
Since rotation is at a constant speed, it means that the velocity at the rim is faster than velocity near the center. This means that the within a single revolution, more storage media pass under a disk head positioned near the rim than under a disk head positioned near the center.
Back in the old days, hard drives stored data at a constant bit rate, resulting in a fixed number of sectors per track. Sectors near the rim would be larger than sectors in the hub, which was a waste of storage media.
Hard drives nowadays store data at a roughly constant bit density per unit of storage media, so that tracks near the rim contain more data than tracks near the center. Within a single revolution, so you can bulk-read more data from tracks near the rim in the same amount of time. And it is this phenomenon that the disk optimizer takes advantage of.
Bonus chatter: Commenter aidtopia points out that while it’s true that you get more data per second from the outer tracks, it does come at a cost of added latency because you have to move the head to the far edge of the platter in order to get there. You therefore do not want to put frequently-accessed data there, because you’ll be wasting a lot of time seeking. The idea choice for the outer tracks is therefore bulk data that is not used often. And boot files are a great example of this. You need them only once, but when you need them, you need all of them.
Light
Dark
15 comments
I rarely reboot. Is optimizing for boot times the best use of that resource?
Well, bless your heart. I myself never reboot my coworker’s computer.
What is your point?
The fastest area of the disk should be used for things you do the most. If the thing you do the most is reboot then sure, it seems like a great idea. If not then it seems like a premature optimization.
Nowadays of course your coworkers should get an SSD.
I always shutdown and reboot my PCs because it’s a waste of energy to keep unused devices powered on or in stand-by. I mean, if you sum it up, we literally need several gigawatt power plants just for convenience and I think this is a no go. With a SSD, or even a modern HDD, boot times are neglectable today anyways. For example, the monitor of my desktop PC is not slow to become ready but it takes longer to power up than the boot process.
Putting the boot information on the outer cylinders isn’t (only) about optimizing for boot times. The outer cylinders typically require the farthest seeks, so the latency is bad. You don’t want your hot files there.
Putting the boot files out at the edge is good for boot times (where the bandwidth bonus exceeds the seek latency you’re probably already paying for), but it also means those big files won’t be taking up valuable real estate in the “middle” of the drive, where you want the smaller files you hit frequently.
And here was me thinking that the heads must be at cylinder 0 in order to read the boot sector, so why not make use of that and put as much other boot-time data there as possible?
The boot is only at cylinder 0 because it is easier if you always boot from a known place and everything has to have a 0.
But the hard drive controller manufacturers decided which end of the disk was 0.
They probably made the same decision, that 0 should be the faster area of the disk.
If you start allocating the fastest then it feels really fast when you first install, but gets slower as you install all the files (that you’ll end up using more).
Back in the 1980s, I worked for a company that built systems on Data General minis. There was one model of disk, I think the 73 MB, for which the 16-bit OS had to be installed very close to the outer edge, or it wouldn’t boot. (On all disk models, the OS had to be a contiguous file, though the overlay file didn’t. ) I remember that prudent operators would sometimes lay down extra copies there to reserve space for upgrades.
That rings a bell. I think it was something like the filesystem used 16-bit block numbers, but the operating system loader was optimised to use 8-bit numbers, so it all had to live in the first 256 blocks, 0000 to 00FF.
But you should also mention that this layout (lower-numbered block numbers are faster) is not contractual. So, one should not rely on this implementation detail. 😉
There is nothing preventing a disc manufacturer from arranging it in the opposite order, that is, the highest-numbered block numbers would be the fastest then.
Or they can lay it out as follows: First, head 0 is filled completely. Then, head 1 is filled completely. Then, head 2, and so on.
This way, the block number vs. performance graph will look mostly like sawteeth.
This has been done before, so, this is not completely made up.
I never understood why Windows did not do more of this, specifically move stuff like .msi and service pack backup files to the slow part of the disk.
It would be cool if a API was added so you could give a hint to a file handle if the file storage area should be normal or slow.
Within the Windows team that sounds like a potentially useful feature.
But I have a hard time imagining any PHB at, say, Litware, agreeing that any of the files in their product should volunteer for second class status performance-wise versus competing products. It’s another variation on the taller ladders & walls situation.
I have a defrag question – why is mrt.exe always so heavily fragmented?
Having more sectors per track on the outer cylinders is called zone bit recording. Rather than having to compute the sectors per track for a given cylinder, you divide the cylinders into “zones” and determine the number of sectors per track based on what zone it’s in.
While it seems like an obvious and straight-forward optimization for data density, it can add a surprising amount of complexity.
For example, when you change zones, you not only need to know the number of sectors per track, you might have to adjust the clocking registers used to manage the frequency of the write heads.
Also, you usually put your spare sectors at the end of each zone rather than at the end of the drive. So if you encounter a bad sector, you don’t have to seek very far to get to a spare, nor do you have to adjust the read-write frequencies. That is, until you’ve used up all the spares in your zone. Then you need a way to select a spare from an adjacent zone and have a way to maintain that mapping.
Putting files on the outer cylinders is great for high bandwidth transfers, but they typically also have latency (because of the extra seek time from the “center” of the drive where, ideally, most of the hot files should be). So it’s perfect for rare things that need to bring in a lot of data at once, like boot-time operations.
Years’n’years ago I wrote a disk optimiser that would put the files in a directory in adjacent sectors to the ones occupied by the directory. The rationale being that after scanning the directory for the file’s information there would be minimal steps from the directory to the sectors holding the files.