Distributed File System
Distributed File System
Flat file
Client service
module
Distributed File Service Architecture (Cont.)
• The Client module implements exported interfaces of flat file and
directory services available on server side.
• Responsibilities of various modules can be defined as follows:
• Client Module
It runs on each computer and provides integrated service (flat file and
directory) as a single API to application programs. For example, in UNIX
hosts, a client module emulates the full set of Unix file operations.
It holds information about the network locations of flat-file and directory
server processes; and achieve better performance through implementation
of a cache of recently used file blocks at the client.
Distributed File Service Architecture (Cont.)
• Directory service
Provides mapping between text names for the files and their Unique File
dentifiers (UFIDs).
Clients may obtain the UFID of a file by quoting its text name to directory service.
Directory service supports functions needed to generate directories and to add
new files to directories.
✔ /var/log/syslog
• Flat file service
Concerned with the implementation of operations on the contents of file.
Unique File Identifiers (UFIDs) are used to refer to files in all requests for flat file
service operations.
✔ UFIDs are long sequences of bits chosen so that each file has a unique among all of the files in
a distributed system.
Distributed File Service Architecture (Cont.)
• Create file operation
• Read / write file operation
• Delete file operation
Client Server
computer computer
Application Application Directory
program program service
Flat file
Client service
module
Distributed File System Examples
• Network File System (NFS)
User programs can issue file operations for local or remote files without
distinction
Other distributed file systems may be present that support UNIX system
calls, and if so, they could be integrated via VFS
Keeps track of the available file systems – both local and remote
Virtual File System (Cont.)
• The virtual file system layer has one VFS structure for each
mounted file system and one v-node per open file
A VFS structure relates a remote file system to the local directory on which
it is mounted
✔ If the file is local, the v-node contains a reference to the index of the local file (an
i-node in a UNIX implementation).
✔ If the file is remote, it contains the file handle of the remote file.
Hierarchic File System
• A hierarchic file system consists of a number of directories arranged in a tree
structure.
• Any file or directory can be referenced using a pathname – a multi-part name
• A UNIX-like file-naming system can be implemented by the client module
using the flat file and directory services that we have defined.
• A tree-structured network of directories is constructed with files at the leaves
and directories at the other nodes of the tree.
The root of the tree is a directory with a ‘well-known’ UFID.
• A function can be provided in the client module that gets the UFID of a file
given its pathname. The function interprets the pathname.
Pathname starting from the root, using Lookup to obtain the UFID of each directory in the
path.
Mount Service
• The mounting of subtrees of remote file systems by clients is supported
by a separate mount service process that runs at user level on each NFS
server computer.
• On each server, there is a file with a well-known name (/etc/exports)
containing the names of local file systems that are available for remote
mounting.
• An access list is associated with each file system name indicating which
hosts are permitted to mount the file system
• Mount operation:
mount(remotehost, remotedirectory, localdirectory)
• Each client maintains a table of mounted file systems holding:
< IP address, port number, file handle>
Mount Service (Cont.)