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.

Topics

Other

Author

Raymond Chen

Raymond has been involved in the evolution of Windows for more than 30 years. In 2003, he began a Web site known as The Old New Thing which has grown in popularity far beyond his wildest imagination, a development which still gives him the heebie-jeebies. The Web site spawned a book, coincidentally also titled The Old New Thing (Addison Wesley 2007). He occasionally appears on the Windows Dev Docs Twitter account to tell stories which convey no useful information.

15 comments

Discussion is closed. Login to edit/delete existing comments.

Jonathan Harston December 2, 2020

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.
aidtopia December 1, 2020

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...
Read more
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.

Read less
Goran Mitrovic November 27, 2020

I have a defrag question – why is mrt.exe always so heavily fragmented?
skSdnW November 25, 2020

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.
- Aged .Net Guy November 25, 2020
  
  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.