next up previous
Next: 3 Elastic Quota File Up: The Design and Implementation Previous: 1 Introduction

2 Elastic Quota Usage Model

To explain how elastic quotas are used, we first define some key elastic quota file concepts. A file can be either persistent or elastic. A persistent file is a file whose space will never be automatically reclaimed by the system. In a traditional file system, all files are considered persistent. An elastic file is a file whose space may be reclaimed on demand by the system. A file can change from being persistent to elastic and vice versa, but it can never be both at the same time. Each user is assigned an elastic quota, which is analogous to a traditional disk quota. Like traditional quotas, an elastic quota is a fixed-size limit that restricts the maximum amount of disk space that a user can use for storing persistent files. Unlike traditional quotas, an elastic quota does not limit the amount of disk space used for elastic files.

Users are only allowed to exceed their quotas by declaring files as being elastic. When a file is declared elastic, the system is effectively informed that the file may be removed from the system at a later time if disk space becomes scarce. The elastic quota system provides a contract between users and the system. The system agrees to allow users to use more than their quotas of disk space. In return, users agree that the system will be able to remove enough files to bring the users back within their quotas when disk space becomes scarce. The system guarantees that only elastic files are ever removed.

The elastic quota system provides a flexible interface consisting of two components: the EQFS interface and the rubberd configuration interface. The EQFS interface is a simple file system interface for declaring files elastic and managing persistent and elastic quotas. The rubberd configuration interface supports administrator-defined and user-defined policies that determine how and when disk space is reclaimed. We defer our discussion of the rubberd interface until Section 4 and focus first on the EQFS interface.

To allow users, user-level tools, and applications to declare files as elastic, EQFS provides a file system interface that can be used explicitly by users or as the basis for building tools for elastic file system management. To provide information about the elasticity of files without requiring any modification to existing file system utilities, the interface provides multiple views of the same directory hierarchy. These views enable users to declare files as elastic, and separate elastic and persistent files using common file operations. There are four views, which are most easily thought of as four directories. We refer to these views as /home, /ehome, /persistent, and /elastic.

Each view appears as a separate directory. /home and /ehome are two identical views of the file system. The key difference between the two is that files created in /home are persistent, whereas files created in /ehome are elastic. All other file operations are identical. /persistent and /elastic are read-only views of the file system. In /persistent only persistent files are visible; conversely in /elastic only elastic files are visible.

In all cases, users can use existing utilities for copying files, moving files, listing directories, editing files, etc. without requiring any changes to such tools to determine which files are elastic versus persistent. Furthermore, as discussed in Section 3, the interface can be supported in a way that requires no changes to existing file systems.

Consider the following example of how the EQFS file system interface provides its elastic functionality using common file operations. Suppose there is a student Mary who is using her computer account on a school system that provides elastic quotas. Mary's home directory is located at /home/mary. Mary often receives large MIME attachments, which she can not decode into her home directory without exceeding her quota. She simply extracts them into /ehome to use them. Since she still has the file within her mail inbox, there is no danger of losing the data.

The flexibility of the elastic quota usage model is that a file's effective location does not change when its status changes from persistent to elastic or vice versa. For instance, using this model for temporary storage is quite different from using a directory for just temporary files, such as /tmp. For example, developers may want to compile a large package, but do not have space for the temporary files associated with the build. Without elastic quotas it is necessary to edit Makefiles or move the entire tree to /tmp. Using the elastic quota usage model, developers would simply change directories from /home to the corresponding directory under /ehome and then can compile the program, without worrying about exceeding their quota.

The EQFS interface provides a useful foundation upon which developers and users can easily create tools that use normal file system interfaces to take advantage of elastic quota functionality. For example, higher-level functionality could be built on top of elastic quotas to allow users to specify that certain types of files should be considered elastic after some period of time. One policy may be that *.o files should be considered elastic if they were created more than a week ago. This could easily be implemented using a cron job to find and move files from /home to /ehome.

next up previous
Erez Zadok 2002-06-21