MITRA Introduction -- Multi-Zone Disks

Go backward to File System Design
Go up to One Disk Configuration
Go forward to PM-driven Scheduling

Multi-Zone Disks

A trend in the area of magnetic disk technology is the concept of zoning. It increases the storage capacity of each disk. However, it results in a disk with variable transfer rates with different regions of the disk providing different transfer rates. Figure 4 shows the transfer rate of the 23 different zones that constitute each of the Seagate disks. (Techniques employed to gather these numbers are reported in [GSZ95].)

A file system that does not recognize the different zones might be forced to assume the bandwidth of the slowest zone as the overall transfer rate of the disk in order to guarantee a continuous display. In [GKSZ96], we described two alternative techniques to support continuous display of audio and video objects using multi-zone disks, namely, FIXed Block size (FIXB) and VARiable Block size (VARB). These two techniques harness the average transfer rate of zones. Mitra currently implements FIXB(6). It organizes an EVEREST file system on each region of the disk drive. Next, it assigns the blocks of each object to the zones in a round-robin manner. The blocks of each object that are assigned to a zone are stored as a single EVEREST file. In the catalog, Mitra maintains the identity of each EVEREST file that constitute a clip, its block size, and the zone that contains the first block of this clip.

Figure 5: Memory requirement with FIXB

The Scheduler scans the disk in one direction, say starting with the outermost zone moving inward. It recognizes m different zones, however, only one zone is active per time period (denoted as a global variable Z_Active). The bandwidth of each zone is multiplexed among all active displays. Once the disk reads data from the innermost zone, it is repositioned to the outermost zone to start another sweep. The time to perform on weep is denoted as T_scan. The block size is chosen such that the amount of data produced by Mitra for a PM during one T_scan equals the amount of data consumed at the PM. This requires the faster zones to compensate for the slower zones. As demonstrated in Figure 5, data accumulates at the PM when outermost zones are active at the Scheduler and decreases when reading blocks from the innermost zones. In this figure, T_Mux(Z_i) denotes the duration of a time that a zone is active. It is longer for the innermost zone due to their low transfer rate. In essence, FIXB employs memory to compensate for the slow zones using the transfer rate of the fastest zones, harnessing the average disk transfer rate.

If X₀ is assigned to a zone other than the outermost one (say Z_X₀) then its display may not start at the end of the time period that retrieves X₀ (i.e., T_MUX(Z_X₀)). This is because both the retrieval and display of data on behalf of a PM is synchronized relative to the transfer rate of the outermost zone to ensure that the amount of data produced during one sweep is equivalent to that consumed. If the display is not delayed, then the PM might run out of data and incur hiccups. By delaying the display at a PM, the system can avoid hiccups. In [GKSZ96], we detail analytical models to compute the duration of a delay based on the identity of Z_X₀.

A drawback of recognizing a large number of zones is a higher startup latency. Mitra can reduce the number of zones by logically treating one or more adjacent zones as a single logical zone. This is achieved by overlaying a single EVEREST file system on these zones. Mitra assumes the transfer rate of the slowest participating zone as the transfer rate of the logical zone to guarantee hiccup-free displays.