A Remote File Mechanism
Networking makes the far-away the here-and-now.
Chapter 16 discusses a network interface and a device driver that uses the hardware
interface to send and receive packets. Chapter 18 considers disk hardware and the
block transfer paradigm. Chapter 19 explains how a file system creates high-level
abstractions, including dynamic files, and shows how files can be mapped onto a disk.
This chapter expands the discussion of file systems by considering an alternative
that uses a remote file server. That is, instead of implementing the file abstraction
directly on hardware, the operating system relies on a separate computer called a server.
When an application requests a file operation, the operating system sends a request to
the server and receives a response. The next chapter extends the discussion by showing
how a remote and local file system can be integrated.
20.2 Remote File Access
A remote file access mechanism requires four conceptual pieces. First, an operat-
ing system must contain a device driver for a network device (such as an Ethernet).
Second, the operating system must also contain protocol software (such as UDP and IP)
that handles addressing so the packets can reach the remote server and replies can re-
turn. Third, the operating system must have remote file access software that becomes a
client (i.e., forms a request, uses the network to send the request to the server and re-
460 A Remote File Mechanism Chap. 20
ceive a response, and interprets the response). Whenever a process invokes an I/O
operation on a remote file (e.g., read or write), the remote file access software forms a
message that specifies the operation, sends the request to the remote file server, and
processes the response. Fourth, a computer on the network must be running a remote
file server application that honors each request.
In practice, many questions arise about the design of a remote file access mecha-
nism. What services should a remote file server provide? Should the service permit a
client to create hierarchical directories, or should the server only permit a client to
create data files? Should the mechanism allow a client to remove files? If two or more
clients send requests to a given server, should the files be shared or should each client
have its own files? Should a file be cached in the memory of the client machine? For
example, when a process reads a byte from a remote file, should the client software re-
quest one-thousand bytes and hold the extra bytes in a cache to avoid sending requests
to the remote server for successive bytes?
20.3 Remote File Semantics
One of the primary design considerations surrounding remote file systems arises
from heterogeneity: the operating system on the client and server machines may differ.
As a result, the file operations available to the remote server may differ from the file
operations used on the client machine. For example, because the remote file server
used with Xinu runs on a Unix system (e.g., Linux or Solaris), the server supplies func-
tionality from the Unix file system.
Most of the Xinu file operations map directly to Unix file operations. For exam-
ple, Xinu uses the same semantics for read as Unix — a request specifies a buffer size
and read specifies the number of data bytes that were placed in the buffer. Similarly, a
Xinu write operation follows the same semantics as a Unix write .
However, Xinu semantics do differ from Unix semantics in many ways. Each
Unix file has an owner that is identified by a Unix userid; Xinu does not have userids,
and even if it did, they would not align with the userids used by the server. Even small
details differ. For example, the mode argument used with a Xinu open operation allows
a caller to specify that the file must be new (i.e., must not exist) or that the file must be
old (i.e., must exist). Unix allows a file to be created, but does not test whether the file
already exists. Instead, if the file exists, Unix truncates the file to zero bytes. Thus, to
implement the Xinu new mode, a remote server running on a Unix system must first test
whether the file exists and return an error indication if it does.
20.4 Remote File Design And Messages
Our example remote file system provides basic functionality: a Xinu process can
create a file, write data to the file, seek to an arbitrary position in the file, read data
from the file, truncate a file, and delete a file. In addition, the remote file system allows