Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Mail Systems
Eclipse Documentation

How To Guides
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Problem Solutions




NOTE: CentOS Enterprise Linux is built from the Red Hat Enterprise Linux source code. Other than logo and name changes CentOS Enterprise Linux is compatible with the equivalent Red Hat version. This document applies equally to both Red Hat and CentOS Enterprise Linux.

5.2. Storage Addressing Concepts

The configuration of disk platters, heads, and access arms makes it possible to position the head over any part of any surface of any platter in the mass storage device. However, this is not sufficient; to use this storage capacity, we must have some method of giving addresses to uniform-sized parts of the available storage.

There is one final aspect to this process that is required. Consider all the tracks in the many cylinders present in a typical mass storage device. Because the tracks have varying diameters, their circumference also varies. Therefore, if storage was addressed only to the track level, each track would have different amounts of data — track #0 (being near the center of the platter) might hold 10,827 bytes, while track #1,258 (near the outside edge of the platter) might hold 15,382 bytes.

The solution is to divide each track into multiple sectors or blocks of consistently-sized (often 512 bytes) segments of storage. The result is that each track contains a set number[1] of sectors.

A side effect of this is that every track contains unused space — the space between the sectors. Despite the constant number of sectors in each track, the amount of unused space varies — relatively little unused space in the inner tracks, and a great deal more unused space in the outer tracks. In either case, this unused space is wasted, as data cannot be stored on it.

However, the advantage offsetting this wasted space is that effectively addressing the storage on a mass storage device is now possible. In fact, there are two methods of addressing — geometry-based addressing and block-based addressing.

5.2.1. Geometry-Based Addressing

The term geometry-based addressing refers to the fact that mass storage devices actually store data at a specific physical spot on the storage medium. In the case of the devices being described here, this refers to three specific items that define a specific point on the device's disk platters:

  • Cylinder

  • Head

  • Sector

The following sections describe how a hypothetical address can describe a specific physical location on the storage medium. Cylinder

As stated earlier, the cylinder denotes a specific position of the access arm (and therefore, the read/write heads). By specifying a particular cylinder, we are eliminating all other cylinders, reducing our search to only one track for each surface in the mass storage device.

Cylinder Head Sector
1014 X X

Table 5-1. Storage Addressing

In Table 5-1, the first part of a geometry-based address has been filled in. Two more components to this address — the head and sector — remain undefined. Head

Although in the strictest sense we are selecting a particular disk platter, because each surface has a read/write head dedicated to it, it is easier to think in terms of interacting with a specific head. In fact, the device's underlying electronics actually select one head and — deselecting the rest — only interact with the selected head for the duration of the I/O operation. All other tracks that make up the current cylinder have now been eliminated.

Cylinder Head Sector
1014 2 X

Table 5-2. Storage Addressing

In Table 5-2, the first two parts of a geometry-based address have been filled in. One final component to this address — the sector — remains undefined. Sector

By specifying a particular sector, we have completed the addressing, and have uniquely identified the desired block of data.

Cylinder Head Sector
1014 2 12

Table 5-3. Storage Addressing

In Table 5-3, the complete geometry-based address has been filled in. This address identifies the location of one specific block out of all the other blocks on this device. Problems with Geometry-Based Addressing

While geometry-based addressing is straightforward, there is an area of ambiguity that can cause problems. The ambiguity is in numbering the cylinders, heads, and sectors.

It is true that each geometry-based address uniquely identifies one specific data block, but that only applies if the numbering scheme for the cylinders, heads, and sectors is not changed. If the numbering scheme changes (such as when the hardware/software interacting with the storage device changes), then the mapping between geometry-based addresses and their corresponding data blocks can change, making it impossible to access the desired data.

Because of this potential for ambiguity, a different approach to addressing was developed. The next section describes it in more detail.

5.2.2. Block-Based Addressing

Block-based addressing is much more straightforward than geometry-based addressing. With block-based addressing, every data block is given a unique number. This number is passed from the computer to the mass storage device, which then internally performs the conversion to the geometry-based address required by the device's control circuitry.

Because the conversion to a geometry-based address is always done by the device itself, it is always consistent, eliminating the problem inherent with giving the device geometry-based addressing.



While early mass storage devices used the same number of sectors for every track, later devices divided the range of cylinders into different "zones," with each zone having a different number of sectors per track. The reason for this is to take advantage of the additional space between sectors in the outer cylinders, where there is more unused space between sectors.

  Published under the terms of the GNU General Public License Design by Interspire