Recall that, in the context of operating systems, a file system is the part of the operating system responsible for managing files and directory structures.
Traditional file systems are local to an individual machine. The file system provides an interface between the operating system and the device drivers for the disks.
At this level, the file system is concerned with the following things:
Physical layout on the disk
As already discussed the disk is logically thought of as an array of sectors or blocks, which the individual device drivers map onto the physical disks. Often some parts of the disk are reserved for superblocks or other structures that hold information required by the file system.
Another issue is the method by which space for files is allocated and addressed on the disk (contiguous, linked, indexed, etc.).
Structure of the directory files
Most modern file systems use the concept of directories or folders to allow user files to be organized in a logical, useful way. The file system defines the structure of these files and is responsible for maintaining them
How the file space is seen by the operating system
The entire file system space can be viewed by the operating system in several different ways:
User is aware of physical disks and/or devices
A file on these systems is usually specified by both a disk and a directory, such as DISK:DIRECTORY/FILE.
In this type of system the user knows that the file he or she wants is on a particular logical disk. For example, on MS-DOS and it's derivatives drives are referred to with A:, B:, C:, etc. Actually, in many cases its not physical disks that are being referred to, but disk partitions, which can be thought of as logical disks.
VAX/VMS works in a similar but more general way, allowing logicals to be defined that further blur the distinction between disks and directories. For example, suppose that a users home directory was SYS$CSROOT:[CS121.JSMITH] and that SYS$CSROOT was a logical for FAITH$DKA100:[CS0.]. Then the logical definition
Physical devices are hidden from user
The Unix file system is conceptually a single tree regardless of how many physical disks comprise it. The disks are mounted at particular points called mount points in the tree. These mount points must be previously existing directories whose contents are unavailable as long as a disk is mounted over them.
It is usually possible to find out exactly where a particular file actually resides, but the user has to search this information out and is not normally required to know it.
Networked systems are collections of computers that are connected together by some form of network in such a way that users are aware of the different computers that comprise the network.
Distributed systems are collections of computers also connected by some form of network, but in such a way that the user is not aware of the different computers. The entire distributed system should appear as a single computer system.
In practice true distributed systems are difficult to achieve.
The goal of a distributed file system (DFS) is to provide access to files on multiple computers in a way similar to how files on the local computer are accessed.
Naming
One design goal of most file systems is to provide a convenient name space for users. This usually means one or more levels of abstraction above the hardware layer. Naming refers to the mapping of logical objects (files as conceived of by the user) and physical objects (files as stored on the disks).
Transparency
In the context of distributed file systems, this term refers to the additional level of abstraction that hides the network location of the file from the user. Ideally the file appears as if it is on the local host rather than on some other host on the network.
It becomes helpful to distinguish between the two following related but distinct concepts:
Location transparency: The name of the file does not give any indication as to the actual (physical) location of the file.
Location independence: The name of the file does not need to be changed if the file's physical network location changes.
The second of these two concepts is stronger.
Most current DFSs provide static, location-transparent mapping.
This includes NFS. One notable exception is Andrew.
Naming schemes
File names are a combination of host name and local file name
This scheme is not location-transparent, but provides for names that are unique in the network name-space. This scheme is used by DECnet. For example, on FAITH you can type
and you will see the directory entry for the directory program on PEACE.
Merge remote directory tree into local directory tree
This is the approach taken by NFS, primarily because it is meshes nicely with the standard Unix file system's naming scheme. For example, if a machine ernie exports the /usr/local directory on it's local file system, and the machine bert mounts this remote directory on it's local file system on the /usr/in-house directory, then referring to the file /usr/in-house/bin/gcc on bert really refers to /usr/local/bin/gcc on ernie.
Use a single global name structure spans all file names on all systems
This allows for location-independence, but causes problems for systems (e.g. Unix) that expects certain files on each local system (e.g. /etc/passwd, /dev/console, etc.).
Overview of the remote service mechanism
In one of the most common ways to implement distributed file systems is using the remote service mechanism. When a user wants to open a file that is actually on a remote machine, the following events happen:
The user attempts to open the file using the location-transparent file name.
The local file system - or the local operating system - recognizes that the file is not local.
A request is sent to the remote machine to open the file
The response to this request is processed by the local machine's file system (or operating system) and a valid file descriptor is given to the user
At this point the user can read from and/or write to the file. However, just as when the file was opened, the desired operations are actually performed on the remote machine on behalf of the user.
One way to think of this is that there is just one additional layer of abstraction between the file system and the hardware. Rather than the file system interacting directly with the device drivers, it interacts with the remote file system (with some form of network interface between them) which in turn interacts with the device drivers on the remote machine.
Remote Procedure Call (RPC)
One way (probably the most common way) to implement a remote service mechanism is with the remote procedure call (RPC) paradigm. This allows certain library routines to be called on a remote machine. In order to do this, the two machines need some way to establish a logical connection; this may happen for each procedure call or once for multiple procedure calls.
Caching
For performance reasons, DFSs usually use some form of caching to reduce the network traffic just as regular file systems use caching to reduce the number of physical disk accesses. Actually in the case of DFSs, caching not only reduces the network traffic but also reduces disk IO.
One major issue with regard to caching is where is the cache stored? There are basically two choices:
Main-memory: In this case the cached data from the remote file is kept in volatile memory on the local machine. This has the obvious advantage of speed and the obvious disadvantage when the power goes off.
Local disk: In this case the cached data from the remote file is kept on a local disk. This solves the volatility problem but at the expense of performance.
Regardless of where the cache is kept, care must be taken to ensure that when the cached data is changed that the remote file is updated properly and that it remains consistent in the face of all network accesses. This relates to the cache update policy:
Immediate update: Whenever any cache data is modified the remote file is updated. This ensures the highest reliability of any update scheme but performance suffers due to the resulting remote file access time.
Delayed update: Updates to the remote file are not performed immediately, but occur sometime after the cached data has been modified. There are several variations of delayed update schemes:
One option is to update the remote file when a modified block is about to flushed from the local cache. Since it is possible for a modified block to remain in the local cache for a relatively long time, this approach is not very reliable, even though it is efficient.
Another approach is the same as above but to also periodically update the remote file using modified cache blocks (which can then be marked as unmodified or flushed).
Update-on-close: Update the remote file when it is closed. This will have performance advantages over delayed update when files are open for a relatively long time and there are frequent modifications to them.
Stateful service
Service begins by the establishment of a connection and the creation of an identifier for the connection.
All subsequent communication between the server and the client use the identifier.
It is possible that both client and server retain information regarding the status of the connection.
Stateless Service
Each request from the client to the server is self-contained and is independent from any other requests.
The server does not retain any information about the clients (e.g. a table of open files, etc.) Of course, the server may well log each request.
Since more information must be packed into each message, and since the server may have to repeatedly carry out operations on behalf of the same client (open file, read data, send to client, close file) a stateless service is generally slower than a Stateful service.
The big advantage of a stateless service is it's integrity. Even when the server is terminated and restart the client requests can still be served -- no information was lost.
$Id: distfile.html,v 1.4 2000/05/01 14:40:26 senning Exp $
These notes were written by J. Senning of Gordon College in May 1998. They are based on the book Operating System Concepts by Silberschatz and Galvin, Addison-Wesley, 1998.