Filling in Partially Cached files

Our design exhibits a strong preference for completely cached files. For example these files do not require a kernel structure to track the valid pages, they can persist across reboots, and they do not increase pressure on the limited in-memory inode resources (while a file is being filled in, two inode structures are maintained--one for the remote file, and one for the local cache file). However, many files are not read in their entirety. A prime example is also the most important: dynamically paged-in program binaries. To combat the possibility that long-term operation could lead to a cache full of mostly-complete files, we created a way to bridge the gap between NFS-like caching at page granularity for performance of small reads on many files and AFS-like caching of whole files for long-term local disk storage.

To accomplish this, we have a background kernel thread called nfsfillind which looks for partially cached files and attempts to take advantage of idle time to fill them in. When network traffic is low, this thread periodically looks at the set of partially cached files. It chooses one that would benefit from being filled-in (the simple metric we use is fewest-remaining pages first, with ties broken by total file size) and reads in an unread page, saving it to the local disk cache. In this way, we avoid insisting that the first read of a file get all the pages from the server immediately, but instead choose to get the rest of a file when the system is idle.

This ``fill-in'' process will continue as long as there are partially cached files.¹³ In order to allow partially cached files to be kept and filled in even if the original user process which read the file has closed it, the inode for the local cache file is augmented with the NFS file handle for the file. Using this handle, the nfsfillind process can read pages from the server even if the inode representing the NFS version of the file has left memory.¹⁴