Distributed File Sytsem Essay Research Paper IntroCODA

Distributed File Sytsem Essay, Research Paper

Intro

CODA is an experimental distributed file system being developed at Carnegie Mellon University. Dr. M. Satyanarayanan heads this group whose purpose is to design and implement a distributed file system that allows for transparent mobile computing in a client server environment. The goals set forth for CODA include disconnected operation for mobile clients, failure resistance, performance, scalability and security.

Architecture

Most of the aspects of CODA’s basic architecture are inherited from its predecessor AFS (Andrew File System). Like AFS, CODA makes a distinction between servers and clients. The CODA workstation servers consist of partitions available to the file server. The partitions are made up of volumes that contain files. The volumes are set up like a directory structure, a root directory and the tree below it. A typical server would have hundreds of volumes of around 10MB each. The use of volumes helps to make large amounts of data more manageable and flexible. CODA stores volume and directory information along with access control lists and file attributes in raw partitions. These partitions are accessed through a log based recoverable virtual memory package (RVM). Only the file data is stored in the server partition files.

Each of the volumes has a name and an ID. Volumes can be mounted anywhere in /coda except for under existing directories. A new directory will be created as part of the mount process (the volume name cannot conflict with existing directories in order to eliminate confusion). CODA makes the mounting points invisible to the user; they appear as regular directories.

Files in CODA are identified by a FID (File identifier). The Fid consists of three 32 bit integers: the VolumeId, a VnodeId and an Uniquifier. The VolumeId identifies the volume the file resides in, the VnodeId is the inode number of the file and the Uniquifier guarantees no FID is ever used more than once.

CODA stores replicated copies of volumes on a group of servers for higher availability and reliability. The list of the servers that hold a copy of the replicated volume is the VSG or Volume Storage Group. Each replicated volume’s VolumeId is also replicated. The replicated VolumeIds keep the VSG and the local volumes of each member together.

Connected Operation

The inner workings of a file system operation in CODA begin in much the same way they would in many other file systems. The client will request a file and a few system calls will be made in relation to the file, that is, the program will ask the kernel for service. The kernel will attempt to find the inode of the file and return a file handle associated with the file. The inode contains the information needed to access the file data and the file handle is used for the opening program. The call to open the file is handled by the Virtual File System (VFS) in the kernel, once the VFS realizes the requested file is in the coda file system the call is passed to Venus. Venus is CODA’s cache manager. IT will first check the client disk cache to see if the file is already in local cache. If the file resides in local cache it is read immediately from the local disk.

In the event the file is not in the client disk cache, Venus must contact the server for the file. The file must come from one of the VSG, but not all VSG are available to each client. This can be due to security considerations, downed server or a myriad of other reasons. Because of this each client has an Available Volume Storage Group (AVSG) that it can contact.

Clients also have a preferred server among the AVSG. The preferred server is chosen by factors such as physical proximity, load and/or server CPU power. Venus also verifies with the other AVSG that the preferred server has the latest copy of the requested data. If this is not true the data is fetched from the server with the latest copy and it is made the preferred server. Venus then notifies the AVSG that one (or more) of its members have stale data. The preferred server then initiates a callback. A callback is a promise made by the server that it will notify the client before allowing any other client to modify the data.

When Venus locates the file it responds to the kernel, which then returns the calling program from the system call. The first time the kernel passes on an open request for a file Venus will get the entire file from the server using remote procedure calls. The file is then stored in the cache area as a container file. It is now an ordinary file on the local disk and read-write operations are almost entirely handled by the local file system. Venus caches all the directory files and attributes. Venus allows operations on the file to proceed without contacting the servers as long as the requested files are present in the cache. When a file is modified and closed Venus updates the AVSG by sending them the new file through parallel remote procedure calls. Removal of or addition of files and symbolic links is also sent to the AVSG. This is one area where updating conflicts could arise. CODA uses an optimistic strategy to deal with these conflicts, which we will discuss later.

Disconnected Operation

CODA allows for transparent disconnected operation. It achieves this through a three-phase process: hoarding, server emulation and rei