The data rate needed for digital audio or compressed video is on the order of one megabit per second, well within available disk transfer rates of 10 megabits per second. Conventional filesystems do not sustain a 1 megabit per second data rate for a file, though they greatly exceed that rate for short bursts. This observation leads the authors to develop a custom filesystem for digital audio and compressed video, the continuous media file system (CMFS). They lay out several requirements for CMFS:
It must sustain predictable data rates.
It must be capable of short bursts that greatly exceed the sustained rate. For example, a video frame may be needed instantaneously.
It must support long-term rate variation, such as variable rate compression.
It must be capable of stop/start behavior for multiple-session synchronization and pause/resume user semantics.
It must support readahead when buffers and bandwidth are available.
CMFS accesses a file in a session that has a guaranteed minimum data rate. Multiple sessions using different data rates, together with non-realtime access, are serviced concurrently. CMFS is implemented as a UNIX process, uses raw disk devices, and supports a socket interface to clients. The reader will wonder why CMFS is not implemented in the kernel using the vnode interface. In practice, in-kernel filesystems carry too much baggage to support realtime behavior. The overhead comes from name lookup, buffer copying, and out-of-band I/O to support cache discipline. Thus, the decision to be outside the kernel is necessary for realtime performance.
CMFS stores each file contiguously on disk. This strategy is effective in some important cases, such as when the disk is nearly empty or for static files that never change their layouts. A more general strategy that allows dynamic updates lays out each file in contiguous chunks, stored in elevator-scan order. Chunk size is determined on a per-file basis; for example, a chunk can be a video frame or the audio for a video frame.
The authors do not present performance numbers for CMFS. Comparable numbers for UNIX File System (UFS) are also needed. I do not feel that CMFS achieves its goals unless it outperforms UFS by a factor of two. The authors should show that CMFS performs within 10 percent of the raw disk rate with a favorable client mix. They do not demonstrate that CMFS can sustain a 1 megabit per second data rate for a single session. It is not clear that CMFS satisfies the other requirements for realtime operation that the authors articulate. They present a convincing analysis of the problem but do not demonstrate conclusively that they have a satisfying solution.
