The Continuous Media File System
David P. Anderson, Yoshitomo Osawa, Ramesh Govindan · USENIX Summer Technical Conference · 1992
Handling digital audio and video data ('continuous media) in a general-purpose file system can lead.to performance problems.. File systems typically optimlze oveiall'average pgrformance, while many audio/videoapplications'need guaeanteed uorst-case performanc--e. These guarantees cannot be provided Uy fast hardwarellone; we must also consider the interrelated software issues of file layout on disk, disk scheduling, buffer space managemenr, and admission control, The Continuous Media File System (oUrSi ii a prototipe filo system that addresses these issues, Introduction sessions) and disk scheduling. CMFS does not Support for digital audio/video (continuous igqt::: lighlevel issues such-as.security, naming media, oi cui has energed as an impori'anu;;tr; ::d,,T3Itlg, or_document shucturing; these are lefl computer sysiem desigi. cM .p.uiiitLr -*ii [,lltg.h:l levels [9, 10]. CMFS simply provides the greaily expand the role of computer .yrte., and will i:tl1ry to source or sink byte sheams to/q9t storage enricti theuser interfaces of'existing upptiuiionr. at-guar-anteed rates' CMFS is influence_d by several Mri_ch effort is being directed to*.0-,,iiie!i.ii;;; lt:;::: CM file systems [1, 5, 8, 1U. However, CM, that is, handlin! CM data in the same fraowire CMFS is more general than these,systems: it supand softwaie frainework as other ?tu.---if,i. Ports. read and write sessions, variable-rate files, and apploach provides advantages in nexiUifity a? Arl m_ultiple_sessions with^^different -rates. .It also superality; however, it introduces performanca probErns ports non-real'time traffic more effectively. because CM traffic contends for hardware iesources tcpU, ?iscirnartilitrt orher traffic. luurccU The Client Interface to CMFS Hardware speedup alone cannot solve these performance problems. It is necessary to schedule resoruces or limit workload (or both) in a way that reflects the performance requiremente of CM traffic. For example, applications might vary data rates (e.g., reducing video resolution or frame rate) in response to changing load conditions. Alternatively, the system might allow applications to ,,reserveii resource capacity; resources must then be scheduled accordingly. The ability to reserve capacity is especially important for file systems, since in general ttre ?atâ rate of stored CM data is fixed. CMFS (Continuous Media File Sysrem) is an experimental disk storage system for integrated CM, CMFS has the following properties: o Clients of CMFS can resewe capacity in the form of sesslons, each of whictr sequentially reads from or writes to a file with 'a. guaranteed ata rate. o Multiple sessions, perhaps with different data rates, can exist concunently, sharing a single disk drive. What exactly is meant by ,,guaeanteed data rate? It is neither feasible nor desirable that CMFS should deliver data at a completely uniform rare, one byte every X seconds. Ideally, the semantics of a CMFS session should accommodate variable-rate files, work-ahead, and client pause/resume. We have developed a semantics that handles these cases in a simple and uniform way. Our semantics also prov.ides--g.duality between reading and writing, ihus simplifying CMFS. To precisely describe the semantics of a CMFS session, we need a model for how CMFS interacts with its clients. Our model is as follows. Each session has a main-memory FIFO buffer for data transfer between CMFS and the client. For a read session, CMFS appends data to the FIFO and the client removes data (blocking when the FIFO is g,qrpty). For a write session, the client appends data (blocking when the FIFO is full) and CMFS removes it. Performance guarantees are defined entirely in terms of data insertion in, and removal from, the FIFO. i Non-real-time traffic is handled concunently. Further details are intentionally left unspecified, Thus CMFS can be used as a general-purpoie since the model can be realized -in varioui ways. file system that handles CM dai-a as *ei1. ' For example, a CM-capable frle system may run in To provide these capabilities, CMFS addresses lE 9l kernel -or in. a protected user-mode viitual several intenelated esign'isuae,airt r,uvo*,;in:19jt:I^:p...(see Figure 1)' I!-may communicate sion control (acceptance or rejection oi-;; with clients via traps (system calls) or via RPC; the Summer '92 USENIX June 8-June lZ, tggz San Antonio. TX 157 The Continuous Media File System FIFO may be a memory-mapped stream [6] or a kernel data structure accessed by read ( ) system calls. Figure 1: A CM-capable file system can run at the user level, communicating with its clients over network connections (a). Alternatively, it can be implemented in an OS kernel, with client data access by a shared-memory FIFO (b). The CMFS prototype is implemented as a user-level UNIX process (Figure 1a), and clients communicate data via flow-controlled network connections. Data is removed from the FIFO of a read session whenever the corresponding network connection is ready to accept data. The Semantics of a Session The semantics of a CMFS session aee defined in terms of a C(t), the ggt G(t) (the start of the FIFO data) and the P(r) (he end of the FIFO data). These are byte indices into the file; C G) is zero when the session starts (f =0). Each session has two parameters: A (its data rate) and f (its cushion). Figure 2a depicts the semantics of a read session: o The logical clock advances at rate R whenever it is less than the get point. Anderson, Osawa, ... o The logical clock stops whenever it equals the get point. i The put point is always at least 7 ahead of the logical clock. These rules imply that if the client removes one byte of data every l/R seconds, it will never block; in other words, the client is guaranteed a data rate of R bytes/second. However, the flow of data need not be smooth or periodic. CMFS promises to stay ahead of the logical clock by a given positive amount (the cushion 1), and the client's behavior determines how the clock advances. These semantics allow CMFS to handle variable-rate files and other non-uniform access in a simple way. CMFS is guided by client behavior; no explicit rate-control calls are needed, and CMFS need not know about