1 Introduction

  The strongest trend in the computer industry today is the miniaturization of workstations into portable ``notebook'' or ``palmtop'' computers. Wireless network links [3] and new internetworking technology [8] offer the possibility that computing sessions could run without interruption even as computers move, using information services drawn from an infrastructure of (mostly) stationary servers.

We contend that operation of mobile computers according to such a model will raise problems that require re-thinking certain issues in file system design. One such issue is how to cope with a client that moves regularly yet unpredictably over a wide area.

Several problems arise when a client moves a substantial distance away from its current set of servers. One is worse latency, since files not cached at the client must be fetched over longer distances. Another problem is increased probability of loss of connectivity, since gateway failures often lead to partitions. The final problem is decreased overall system ``scalability:'' more clients moving more data over more gateways means greater stress on the shared network.

One obvious way to mitigate these problems is to ensure that a file service client uses ``nearby'' servers at all times. A simple motivating example is that if a computer moves from New York to Boston, then in many cases it is advantageous to switch to using the Boston copies of ``common'' files like those in /usr/ucb. As the client moves, the file service must be able to provide service first from one server, then from another. This switching mechanism should require no action on the part of administrators (since presumably too many clients will move too often and too quickly for administrators to track conveniently) and should be invisible to users, so that users need not become system administrators.

We have designed and implemented just such a file system -- it adaptively discovers and mounts a ``better'' copy of a read-only file system which is fully or partially replicated. We define a better replica to be one providing better latency. Running our file service gives a mobile client some recourse to the disadvantages mentioned above. Our mechanism monitors file service latencies and, when response becomes inadequate, performs a dynamic attribute-guided search for a suitable replacement file system.

Many useful ``system'' file systems -- and almost all file systems that one would expect to be replicated over a wide area -- are typically exported read-only. Examples include common executables, manual pages, fonts, include files, etc. Indeed, read-only areas of the file space are growing fast, as programs increase the amount of configuration information, images, and on-line help facilities.

Although our work is motivated by the perceived needs of mobile computers that might roam over a wide area and/or frequently cross between public and private networks, our work can be useful in any environment characterized by highly variable response time and/or high failure rates.

Note that for a client to continue use of a file system as it moves, there must be underlying network support that permits the movement of a computer from one network to another without interruption of its sessions. Several such schemes have been developed [8,7,28,29].

The remainder of this paper is organized as follows. In order to make a self-contained presentation, Section 2 provides brief explanations of other systems that we use in constructing ours. Section 3 outlines our design and Section 4 evaluates the work. Lastly, we mention related work in Section 5 and summarize in Section 6.