Mitra is a realization of several promising design concepts described in the literature. Its primary contributions are two-fold: (1) to demonstrate the feasibility of these designs, and (2) to achieve the non-trivial task of gluing these together into a system that is both high performance and scalable. Mitra is a software based system that can be ported to alternative hardware platforms. It guarantees simultaneous display of a collection of different media types as long as the bandwidth required by the display of each media type is constant (isochronous). For example, Mitra can display both CD-quality audio with a 1.34 Mbps bandwidth requirement and an MPEG-2 encoded stream with 4 Mbps bandwidth requirement (two different media types) at the same time as long as the bandwidth required by each display is constant. Moreover, Mitra can display those media types whose bandwidth requirements might exceed that of a single disk drive (e.g., uncompressed ATV quality video objects requiring 216 Mbps for their display) in support of high-end applications that cannot tolerate the use of compression techniques.
Due to their large size, continuous media objects are almost always disk resident. Hence, the limiting resource in Mitra is the available disk bandwidth, i.e., traditional I/O bottleneck phenomena. Mitra is scalable because it can service a higher number of simultaneous displays as a function of additional disk bandwidth. The key technical idea that supports this functionality is to distribute the workload imposed by each display evenly across the available disks using staggered striping [BGMJ94] to avoid the formation of hot spots and bottleneck disks.
Mitra is high performance because it implements techniques that maximize the number of displays supported by each disk. These techniques both (1) minimize the number of seeks (using EVEREST [GIZ96]) and the amount of time attributed to each seek (GSS [YCK93]) or (2) maximize the transfer rate of multi-zone disks (FIXB [GKSZ96]). Mitra's file system is EVEREST. As compared with other file systems, EVEREST provides two functionalities. First, it enables Mitra to retrieve different files at different block size granularities. This minimizes the percentage of disk bandwidth that is wasted when Mitra displays objects that have different bandwidth requirements. Second, it avoids the fragmentation of disk space when supporting a hierarchy of storage devices [CHL93] where different objects are swapped in and out of the available disk space over time. GSS minimizes the amount of time attributed to each seek by optimizing the disk scheduling algorithm. Finally, FIXB in combination with EVEREST enables Mitra to guarantee a continuous display while harnessing the average transfer rate of multi-zone disks [RW94][GSZ95]. FIXB enables Mitra to strike a compromise between the percentage of wasted disk space and how much of its transfer rate is harnessed. With each of these techniques, there are tradeoffs associated with the choices of values for system parameters. Although these tradeoffs have been investigated using analytical and simulation studies, Mitra's key contribution is to demonstrate that these analyses hold true in practice. It shows that one does not have to rewrite software to support diverse applications with different performance objectives (startup latency versus throughput versus wasted disk space). Instead, there is a single system, where different choices of parameters support different applications.
Several related studies have described the implementation of continuous media servers(1). These can be categorized into single-disk and multi-disk systems. The single-disk systems include [AOG92][LS92][RC95][GBC94]. These pioneering studies were instrumental in identifying the requirements of continuous media. They developed scheduling policies for retrieving blocks from disk into memory to support a continuous display. (Mitra employs these policies as detailed in Display Section.) Compared with Mitra, most of them strive to be general purpose and support traditional file system accesses in addition to a best-effort delivery of continuous media. Thus, none strive to maximize the number of displays supported by a disk using alternative disk scheduling policies, techniques that harness the average transfer rate of disk zones, or strategies that constrained the physical file layout. The multi-disk systems include: Streaming RAID [TPBG93], Fellini [ORS94], and Minnesota's VOD server [HLL+95]. None claims to support either the display of a mix of media types or a hierarchical storage structure, nor do they describe the implementation of a file system that ensures contiguous layout of a block on the disk storage medium. (The authors of Fellini identify the design of a file system such as the one developed for Mitra as an important research direction in [ORS96].) Moreover, all three systems employ disk arrays where the number of disks that are treated as a single logical disk is pre-determined by the hardware. Mitra differs in that the number of disks that are treated as one logical disk is not hardware dependent. Instead, it is determined the bandwidth requirement of a media type. Indeed, if one analyzes two different displays with each accessing a different media type, one display might treat two disks as one logical disk while the other might treat five disks as one logical disk. This has a significant impact on the number of simultaneous displays supported by the system as detailed in Evaluation Section.
Parameter Definition 
Number of media types RC(Mi) Bandwidth required to display objects of media type i RD Bandwidth of a disk B(Mi) Block size for media type i D Total number of disks d Number of disks that constitute a cluster C Number of clusters recognized by the system g Number of groups with GSS k Stride with staggered striping N Number of simultaneous displays supported by the system S Maximum height of sections with EVEREST 
Number of contiguous buddies of section height i that form a section of height i+1
Table 1: Parameters and their definition
Streaming RAID implements GSS to maximize the bandwidth of a disk array and employs memory-sharing to minimize the amount of memory required at the server. It develops analytical models similar to [GR93a][GK95] to estimate the performance of the system with alternative configuration parameters. Fellini analyzes constraint placement of data to enhance the performance of the system with multi-zone disks. The design appears to be similar to FIXB. Fellini describes several designs to support VCR features such as Fast Forward and Rewind. (We hint at Mitra's designs to support this functionality in Conclusion Section and do not detail them due to lack of space.) Neither Fellini nor Streaming RAID present performance numbers from their system. Minnesota's VOD server differs from both Mitra and the other two multi-disk systems in that it does not have a centralized scheduler. Hence, it cannot guarantee a continuous display. However, [HLL+95] presents performance numbers to demonstrate that a mass storage system can display continuous media.
The rest of this paper is organized as follows. In the Overview Section, we provide an overview of the software components of Mitra and its current hardware platform. The Display Section describes the alternative components of the system (EVEREST, GSS, FIXB, and staggered striping) and how they interact with each other to guarantee a continuous display. The Evaluation Section presents experimental performance results obtained from Mitra. As a yard stick, we compare these numbers with theoretical expectations based on analytical models that determine the performance of the system based on the available disk bandwidth [GK95][GKS95]. The obtained results: (1) demonstrate the scalability of the system, (2) show that Mitra attains between 65% to 100% of the theoretical expectations. Our future research directions are presented in Conclusion Section.
Mbps Megabits per second Block Amount of data retrieved per time period on behalf of a PM displaying an object of media type i. Its size varies depending on the media type and is denoted as B(Mi). Fragment Fraction of a block assigned to one disk of a cluster that contains the block. All fragments of a block are equi-sized. Time period The amount of time required to display a block at a station. This time is fixed for all media types, independent of their bandwidth requirement. Page Basic unit of allocation with EVEREST, also termed sections of height 0. Startup latency Amount of time elapsed from when a PM issues a request for an object to the onset of the display.
Table 2: Defining terms