File service

In a distributed file system, a number of computers store and manage files for the whole system. The file service is the specification of what is offered to clients (ie the things that read and write files).

File server

A file server is a process running on a machine that offers at least part of this file service.

A system may have one or more file servers.

Depending on the system, any machine may act as a file server (as in Sun's NFS) or only some may (as in LanManager).

Access model

When a process on one machine wishes to read or write a file, there are two ways this could be done:

upload/download

In this method, when a client attempts to open a file, the entire file is shipped to the client's host. When the client has finished with it, it is sent back to the original server.

This has the advantage that the client can make many accesses to the file without any more network activity.

It has the disadvantage that shipping large files around can slow up the network. Experiments have shown that the majority of file accesses are reads of the first few hundred bytes only, so shipping 10Mbyte files may be a waste.

Remote access

The file remains where it is on the server. Every single read and write must then be done using a network message.

This can result in lots of small messages passing around.

It reduces file storage requirements on the client hosts.

State

How a non-distributed file system works is by maintainance of tables. When a process opens a file, an entry is made in an ``open file table''. This records, for example, where in the file the process is. When a read or write is made, the pointer is moved through the file.

If one of these processes crashes, then the O/S can clean it up, and remove the open file entries. If the whole machine crashes, then that doesn't matter too much. The file system can maintain the state of a process and its open files.

Stateful

In a distributed system the server may also maintain state, by keeping a list of which processes have files open, and the location within this file. If the client crashes though, the server will probably never know about it so it will keep the file open for a process that no longer exists.

Unix file system semantics include this: if a file is open by a process, then even if another removes it, the file does not vanish until the first closes it. If the server maintains state and has Unix semantics, the server will gradually get clogged up with useless files.

What happens if the server itself crashes? Eventually it will come back up, and when it does all the other processes around will send messages like ``give me the next 100 bytes''. The server will have no knowledge of where it is supposed to be in the file.

Stateless

A server could be stateless by not maintaining any tables. In this case the knowledge of where the client is in the file must be kept on the client side. Each file access must then contain all of the information needed to move to the correct location in the correct file.

This means that each network message must be larger as the client passes all the info on each message.

If the server is stateless, file functions such as open may become meaningless

Caching

In a remote access system, a request to read a single byte at a time will clog the network. So a large part will probably be read and put into a local cache. This is similar to the buffering done by functions like getchar() when reading from disk.

It suffers all the same cache coherency problems as every other caching system.

File sharing

In some single computer file-systems, more than one process can have a file open at a time. This happens in Unix: when a pipe is opened or a file is opened, and a fork is done, both parent and child can read/write to the file or pipe.

The Unix file semantics are that if a process writes to a file, then what is written is immediately available to any other process for reading.

If one process is caching parts of a file, and writing to it, while another process is reading the file, then this semantics may be broken.

Unix semantics

Every operation on a file is instantly visible to all processes.

Session semantics

A process that intends to write does so to its own copy. After the process closes the file, the changes are then made visible to other processes.

Immutable files

Once a file is created, nothing can ever write to it again.

Transactions

This is like a network version of locks. A transaction begins, a series of reads or writes take place, and the transaction ends. This is done as an indivisible set of operations.

File replication

Particularly in a large network, the server may be a long way from a client. Files may need to pass through several gateways and routers to get to the client. In this case it makes sense to have multiple copies at different servers, so that the closest copy can be used.

This is a variation of the caching problem: what happens when the ``master'' file changes? All the copies must change too.

A solution is to restrict such replication to immutable files, or to files that only change rarely.

Directory service

Files are known to users by their names. They may be known to the system by other methods (eg Unix inodes). How should files be named in a distributed system?

Location transparency

A user will not care where a file is kept. So whatever naming method is used, ideally it will have no connection to where the file actually is.

Location independance

A user would not care if a file was moved from one server to another as long as they could still access it. If the naming system allows such motion invisibly, then it is location independent.

Global name space

A common system is to have a global name space that all clients share. For example, on the Apollo NFS system, there is a global ``root' directory //. Servers are then accessed below this, and then files on a server below that: //golf/usr/bin/sh This gives location transparency because you do not know where the server is. The server could possibly move. In fact, this is not as good as it could be, because the server name is the machine name.

Local name space

An alternative is for the single host file system naming to remain as it is, with remote file servers occupying a part of this. For example, the Sun NFS system mounts a remote file system into the normal directory space.

NFS

The Sun NFS is a very common network file system, running on a large number of different systems. There is even an NFS server for PCs, so that a Unix system can act as a file server for a PC system.

NFS is a stateless service. There is no open() or close() mechanism for files, because each access message is self-contained.

Any host can act as a server, and any host can be a client of any server. On boot time a system advertises which directories it is exporting.

At boot time (or at any other time) a remote file system can be mounted into the local file system. References to the local file are translated into references to the remote file.

This is done within NFS, by returning a ``file handle'' to the client when it mounts a remote file system. This handle contains - among other things - the inode on the remote machine of the directory that it is exporting. When access to the remote directory is required, its inode is already available.

NFS caches 8k chunks of a file. It attempts to overcome the cache coherency problem by using a timer. After 30 seconds a modified block in the cache will be sent back to the server. This reduces the problem but does not solve it.

DCE

The Distributed Computing Environment has been adopted by a large number of vendors. It includes RPC, time, security, and a remote file system.

When a file is requested, its location is first looked for in the local cache. If it is not there, a Directory File Server is queried for its location. Then it may be copied down to the cache and accessed from there.

The consistency mechanism uses a token. The server keeps track of tokens that have been issued, so it is not stateless.

A token is issued to a process that wants to write to a file. Only one token can be issued per file, so this allows only one writer at any one time. Any number of readers are allowed.

The token can be revoked by the server at any time. In doing so, it may retrieve the modified file from the process that currently has it before revoking permission.

DCE uses a global name space, with root ``/...'' .The network is divided up into ``cells'' which are logical groups of hosts. Files exist on the file system within a cell, so that it is location transparent and independent.

This page is http://pandonia.canberra.edu.au/OS/l14_2.html, copyright Jan Newmarch.
It is maintained by Jan Newmarch.
email: jan@ise.canberra.edu.au
Web: http://pandonia.canberra.edu.au/
Last modified: 11 October, 1995