These notes summarize the contents of the SFS paper from ACM SOSP 1991. You may consult the paper for more details.The SFS server functions as a user-level NFS (Network File System) server: It listens on a port for NFS requests, like
lookup and readdir, and returns NFS
responses. In fact, it can be used as a plain NFS server as
long as normal pathnames are used: these requests are simply
forwarded to the underlying file system. (Recall that NFS
requests are specified relative to a file handle, which
is a name the NFS server uses to identify a file system object.
File handles are often used to address an in-memory cache, and
they can expire when the cache is reset.)
A pathname query may contain an ordinary path as a
prefix. Thes prefix specifies the universe against which the
query defined by the rest of the pathname query is matched. The
query portion of a pathname query contains attributes (field,
value pairs). Field names end in :. For
example, the path /sfs/owner:/sheldon specifies all
the files with the given owner.
Pathname queries use virtual directories, which appear like ordinary directories to the client, but which do not have to be explicitly created. There are two types of virtual directories:
- field virtual directories, whose names end in
:. There is an entry in a field virtual directory for every value the field takes on in the index. Each entry is a value virtual directory (see below). - value virtual directories, whose entries correspond to the files that match the query. In general, the entry name is the same as the original file name. However, if this would generate a name clash, then the entries are systematically renamed.
The SFS server uses two kinds of file handles: a real file hande to refer to actual file system objects, and a virtual file handle to refer to virtual directories.
Two NFS operations are central to the SFS server's
operations: nfs_lookup and
nsf_readdir. In a normal NFS server, a
lookup request takes a file handle representing a
directory and a string representing a file name an returns a
file handle for the file system object with that name in the
given directory. The operation fails if the input file handle
isn't a directory, the name doesn't exist in the directory, or
if permission checking fails. The normal NFS
readdir request takes a file handle for a directory
and a cookie denoting some state and returns the next batch of
directory entries since the last readdir
operation. The state tells the server where it got to in the
last the readdir request. You keep issuing
readdir requests until there aren't any more.
In the SFS server, these operations behave normally for real
file handles. All lookup requests for virtual
directories normally succeed. If the entry is already in the
SFS cache, then its file handle is returned. If the entry is
not in the cache, it is checked for syntactic correctness and,
if it is a legal name, a placeholder is created in the cache,
and a filehandle for the placeholder is returned.
A readdir request (or a lookup
request inside a virtual directory) proceeds normally if the
cache contains the appropriate data. If the directory in
question is a placeholdler, then a directory fault
occurs. This results in the corresponding query being run
against the index, cache entries being manufactured for all the
query results, and then the normal result(s) being returned.
Query results are turned into nodes that appear as symbolic links to the actual files matching the query. The link name is the same as file name unless this would result in a name clash, in which case the entry is systematically renamed.
The system can be configured to make the query results look
like actual files. However, to get the file contents, the
client would need to go through the SFS server. Make the
results appear to be links means that clients can get the
contents without placing additional load on the server.
Modified: 5 May 2008