To simulate the workload of a system, we used file open events from the Sprite file system traces [1]. We chose to consider whole file caching for three reasons. The primary purpose of our work is to avoid the latency of file system accesses; if a whole file can be cached, this reduces the number of transactions with the I/O subsystem on behalf of that file, and in turn reduces the latency of our file system. Whole file caching has been used effectively in several distributed file systems [7,8,18]. In a mobile environment the possibility of temporary disconnection and the availability of local storage make whole file caching the best option.
We split the file system traces into eight 24 hour periods lettered A
through H. Given the time frame and environment under which these
traces were generated, we chose a cache size of four megabytes as a
reasonable size for our initial tests. After developing an
understanding of how the various parameters effected performance, we
explored our model's performance for cache sizes up to 256
megabytes.