next up previous
Next: 7 Conclusions and Future Up: The Design and Implementation Previous: 5 Evaluation


6 Related Work

Elastic quotas are complementary to Hierarchical Storage Management (HSM) systems. HSM systems provide disk backup as well as ways to reclaim disk space by moving less-frequently accessed files to a slower disk or tape. These systems then provide some way to access files stored on the slower media, ranging from file search software to leaving behind a link to the new file storage location in the original file location. Examples of HSM systems include the Network Appliance Snapshot system [3], the Smart Storage Infinet system [26], IBM Storage Management [12], and UniTree [27]. The UniTree HSM system uses a combination of file size and the age of a file in hours to compute the eligibility of a file to be moved to another medium. Rubberd can be similarly configured to clean files based on size and time; however, it also uses more complex algorithms to compute disk space usage over time. Elastic quotas can be used with HSM systems as a mechanism for determining which files are moved to slower storage. Given an HSM system, rubberd could then reclaim disk space when it becomes scarce by moving elastic files to the slower layers of the HSM storage hierarchy.

The design of EQFS builds on previous work in stackable file systems. Rosenthal first implemented file system stacking on top of the VFS interface in SunOS 4.1 [21] more than a decade ago. Skinner and Wong developed further prototypes for extending file systems in SunOS [25]. Guy and Heidemann developed slightly more generalized stacking in the Ficus layered file system [9,10]. Stacking in 4.4 BSD is derived from Heidemann's work. More recently, Zadok and Nieh have developed a system for stackable file system code generation that simplifies stackable file system development and improves file system portability [32]. EQFS uses the idea of file system stacking but does not require much of the functionality in more generalized stacking infrastructures, such as being able to manipulate file data. As a result, the performance overhead of using EQFS is lower than the performance overheads that have been reported for using these other systems.

The idea of unification used in EQFS is similar to the union mounts in 4.4 BSD [17] and Plan 9 [19]. However, EQFS differs from these systems in four ways. First, EQFS provides true fan-out stacking on two underlying directories as opposed to linear stacking. EQFS does not need to use linear stacking in part because it only provides unification of two underlying directories as opposed to unification of an arbitrary number of underlying file systems. Second, EQFS does not require complex mechanisms to resolve differences in directory structure or file name conflicts in the underlying file systems. Third, EQFS provides not just one unified view of the underlying directories, but two unified views with different semantics for file creation. Fourth and most importantly, EQFS does not treat the underlying directories as read only, eliminating the need for the potentially expensive copy-up operation required on UnionFS. These differences are part of the reason for the much lower performance overhead of EQFS versus more generalized union file systems.

The use of a disk cleaner to reclaim disk space consumed by elastic files has some similarities to mechanisms for supporting versioned files in file systems such as Cedar [24] and Elephant [22,23]. Versioning file systems keep track of multiple versions of data automatically. As disk space fills up, versioning file systems reclaim disk space by discarding file versions according to some policy, such as discarding the oldest file versions first. The overall problem of supporting versioned files is different from the problem addressed by the elastic quota system. EQFS can complement versioning systems by differentiating between files that should be versioned (i.e., /persistent) and the temporary files for which versioning is not necessary, while rubberd removes non-versioned temporary files from /elastic.

Much previous work [1,5,11,17,19,30] has been done to develop mechanisms for sharing resource such as processor cycles and network bandwidth such that resources can be utilized fully yet fairly. These resources are elastic in the sense that they can be allocated to a user in such a way that the allocation can be increased or decreased over time based on availability. For example, a processor scheduler enables a group of users to share processor cycles fairly, but allows a user to monopolize the resource when no one else is using it. Elastic quotas can be thought of as a way to make disk space an elastic resource as well. The ability to use disk space elastically opens up new opportunities for applying elastic resource management ideas such as proportional sharing [5,11,17,30] to disk space, a previously unexplored area.


next up previous
Next: 7 Conclusions and Future Up: The Design and Implementation Previous: 5 Evaluation
Erez Zadok 2002-06-21