15.01.2013 Views

U. Glaeser

U. Glaeser

U. Glaeser

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

locks may be a better solution than trying to maintain perfect consistency of the cached copies. The<br />

Sun Microsystems implementation of NFS improves on this approach at a reasonable cost by having<br />

caching clients periodically check to see if their cached copy is still fresh. This solution still allows use of<br />

stale data, but can be tuned to trade-off freshness versus cost. Not caching at all is another solution, but<br />

one with serious performance implications.<br />

When file copies are to be permanently stored at a location, they switch from being cached to being<br />

replicated. Replicating files has several advantages, including superior fault tolerance, high performance<br />

for all file operations, and good support for disconnected operations, which is especially valuable for<br />

mobile computing. Replicating files has a significant cost, however. Beyond the mere storage costs of<br />

keeping multiple permanent copies of the same bits, maintaining consistency among replicated files is a<br />

difficult problem. Generally, replicated file systems must trade the consistency of the replicas against file<br />

system performance. Higher consistency is possible using conservative replication methods, which ensure<br />

that no inconsistent updates to files are possible. Conservative methods often have high costs and limit<br />

file availability, however. Optimistic replication reverses these advantages and disadvantages, offering<br />

lower cost and higher availability at the risk of permitting inconsistencies, which must then be handled<br />

by some method—typically a reconciliation process that tries to merge the results of conflicting updates.<br />

Sample replicated file systems include Coda (which uses optimistic client/server replication) [2] and Ficus<br />

(which uses optimistic peer replication) [3]. The systems in wide commercial use tend not to provide<br />

full functionality replicated file systems because of their cost and complexity.<br />

File replication is widely used in an informal fashion. For example, programs that automatically distribute<br />

new versions of executables to all machines in an office are performing a limited form of file<br />

replication. Mechanisms like the Microsoft Briefcase offer limited forms of file replication for special cases,<br />

such as sharing files between a desktop and a portable computer, where typically only one machine is<br />

active at any given moment. By leveraging the special circumstances of such uses, many of the harder<br />

problems of file replication can be avoided. Such adoption of simple limited expedients for common<br />

circumstances is characteristic of much real-world use of distributed operating systems technology.<br />

File migration is another alternative available to distributed file systems to avoid performance problems.<br />

Files move to the sites that use them. This paradigm requires a high degree of transparency, since all<br />

processes in the system must be able to access all files, local or remote, under the same names. Otherwise,<br />

applications might stop working when the file migrates from the remote to the local site. Further, such<br />

alternatives face difficulties in preventing popular files from moving constantly. This paradigm of remote<br />

data access has been more widely used and studied in the field of distributed shared memory.<br />

Interprocess Communications Services<br />

Many distributed operating systems are designed to support distributed computations, where cooperating<br />

processes run on different nodes. Allowing the processes to cooperate implies that they can exchange<br />

information, which in turn implies a need for interprocess communications (IPC) services.<br />

Single-machine systems have the same requirement, so a variety of IPC services exist for such environments,<br />

including remote procedure calls, messages, and shared memory. Generally, the implementation<br />

of these services in single-machine environments leverages shared hardware. For example, all three<br />

of these services are provided in most single-machine operating systems by writing information into<br />

main memory that can be read by all communicating processes, or by copying information from the<br />

memory of one process into the memory of another, or into buffers provided by the operating system.<br />

The shared hardware and the synchronization provided by the shared processor simplify many issues in<br />

making these IPC services work.<br />

In a normal distributed system, the participating machines can only communicate by passing messages<br />

across a network. Such networks typically do not offer the guarantees available from the shared hardware<br />

of a single machine. Further, the participating machines are typically under the control of their local<br />

processor. No single processor controls the complete collection. These characteristics require different<br />

implementations of familiar IPC services.<br />

© 2002 by CRC Press LLC

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!