100% found this document useful (1 vote)
32 views

Distributed File System

The document discusses distributed file systems and their architecture. A distributed file system allows programs to access remote files in the same way as local files, with comparable performance. It describes the key components of a distributed file system including the client module, directory service, and flat file service.

Uploaded by

Random Guy
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
100% found this document useful (1 vote)
32 views

Distributed File System

The document discusses distributed file systems and their architecture. A distributed file system allows programs to access remote files in the same way as local files, with comparable performance. It describes the key components of a distributed file system including the client module, directory service, and flat file service.

Uploaded by

Random Guy
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 17

CS 3006

Parallel and Distributed Computing


Distributed File System
File System
• File system were originally developed for centralized computer
systems and desktop computers.

• File system was as an operating system facility providing a


convenient programming interface to disk storage.

• File systems are responsible for the organization, storage, retrieval,


naming, sharing and protection of files.

• Files contain both data and attributes.


Distributed File System
• Distributed file systems support the sharing of information in the form of
files and hardware resources.
• A DFS enables programs to store and access remote files /storage exactly
as local ones.
• The performance and reliability of such access should be comparable to
that for files stored locally.
• Recent advances in higher bandwidth connectivity of switched local
networks and disk organization have lead high performance and highly
scalable file systems.
• Functional requirements: open, close, read, write, access control,
directory organization, ..
• Non-functional requirements: scalable, fault-tolerant, secure
Distributed File Service Architecture
• An architecture that offers a clear separation of the main concerns
in providing access to files is obtained by structuring the file service
as three components:
A flat file service
A directory service
Client Server
A client module computer computer
Application Application Directory
program program service

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)

• Andrew File System (AFS)

• Hadoop Distributed File System (HDFS)


NFS Architecture
NFS Architecture (Cont.)
• The NFS client and server modules communicate using Remote
Procedure Calls.

• Sun’s RPC system


Sun RPC was developed for use in NFS. It can be configured to use either
UDP or TCP, and the NFS protocol is compatible with both
Virtual File System (VFS)
• NFS provides access transparency through VFS

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

Distinguishes between local and remote file identifiers

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

The v-node contains an indicator to show whether a file is local or remote.

✔ 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.)

• The file system mounted at /usr/students in the client is actually


the sub-tree located at /export/people in Server 1;
• The file system mounted at /usr/staff in the client is actually the
sub-tree located at /nfs/users in Server 2.
Thank You!

You might also like