Distributed File Systems

1 of 4

http://www.csc.villanova.edu/~huliu/ds/CH8.html

Distributed File Systems

1. General description. Distributed file systems support the sharing of information in the form of files
throughout an intranet. A distributed file system enables programs and users to access remote files
exactly as they do local ones.
a. Summary of storage systems and their properties.
Storage System

Sharing

Persistence

Consistency*

Example

Yes

Distributed
cache/replicas
No

(Non-distributed)
File System
Distributed File
System
Web

No

Unix

Yes

Yes

Yes

Yes

Sun FNS

Yes

Yes

Yes

No

Web Server

*The consistency column indicates whether mechanisms exist for the maintenance of consistency
between multiple copies of data when updates occur.
b.

Basics of File System.

o A file system is responsible for organizing, storing, retrieving, naming, sharing, and protecting
files.
o An interface to characterize the file abstraction.
o Files contains both data and attributes, where data is what we commonly suppose what a file
suppose to contain and the attributes include file size, timestamps, ownership, access control
lists, etc.
o Metadata is used to refer to file attributes, directories, which are special files, and other
persistent information used by file system.
o File system operations.

c.

Distributed File System Requirements.

o Transparency.
o Concurrent file update.
o File replication.
o Hardware and operating system heterogeneity.
o Fault tolerance.
o Consistency.
o Security.
o Efficiency.

2. File Service Architecture.

The overall view of the file service architecture is shown in fig. 1, where there are three components:
client module, directory service, and flat file service.

23-Apr-15 10:02 PM

Distributed File Systems

2 of 4

http://www.csc.villanova.edu/~huliu/ds/CH8.html

Figure 1. Abstract Distributed File System Architecture.

a. File service Components.

o Flat file service is concerned with implementing operations on the contents of files. UFID is
used to identify the file allover the distributed system.
o Directory service. Provides mapping between text name and UFID. E.g., /usr/include/math.h
123456789.
o Client Module integrates and extends the operations of above two services under a single
programming interface.
b.

Programming interface.
Distributed file service has an interface, a set of operations, different from the Unix one.
o Flat file service includes the following operations:
Read (FileId, j, n): j is the starting item and n is the number of items/bytes.
Write (FileId, j, Data): j is the starting item.
Create (): FileId is returned.
Delete (FileId):
GetAttributes (FileId): The set of attributes is returned.
SetAttributes (FileId, Attr):
Note that an absolute starting item is specified in either read() or write () operation,
different from Unix read() and write() where there is a pointer pointing to the current item
and the operations automatically advances the pointer. One advantage with the new operations
is that the operations can be repeated and in fact all operations are repeatable except
create(). Another advantage is the number of operations is reduced so that there are no
such operations as seek(), open(), and close().
o

c.

Directory service includes the following operations:

Lookup (Dir, Name): Locates the text name
AddName (Dir, Name, File):
UnName (Dir, Name):
GetNames(Dir, Pattern):

Other services include hierarchic file system and file grouping.

3. SUN NFS.
Sun NFS closely follows the above abstract model. It provides access/location/mobility transparency.
Other properties it enjoys include hardware and operating system heterogeneity, fault tolerance,
consistency, security, efficiency, etc.
The overview of SUN NFS is depicted in fig. 2.

23-Apr-15 10:02 PM

Distributed File Systems

3 of 4

http://www.csc.villanova.edu/~huliu/ds/CH8.html

Figure 2. Sun NFS architecture.

The operations are listed in the following table:

Operation Protocol
lookup (dirfh, name)

Returns
fh, attr

create (dirfh, name,

attr)

newfh, attr

remove (dirfh, name)

getattr (fh)

status
attr

setattr (fh, attr)

attr

read (fh, offset, count)

attr, data

write (fh, offset, count,

data)

attr

rename (dirfh, name,

todirfh, toname)
link (newdirfh,
newname, dirfh, name)
symlink (newdirfh,
newname, string)

status

readlink (fh)

string

mkdir (dirfh, name,

attr)
rmdir (dirfh, name)

newfh, attr

status
status

status

Description
Returns file handle and attributes for the file name in
the directory dirfh
Creates a new file name in directory dirfh with
attributes attr and returns the new file handle and
attributes
Removes file name from directory dirfh
Returns file attributes of file fh. (Similar to the UNIX
stat system call)
Sets the attributes (mode, user ID, group ID, size,
access time and modify time of a file). Setting the
size to 0 truncates the file
Returns up to count bytes of data from a file starting
at offset. Also returns the latest attributes of the file
Writes count bytes of data to a file starting at offset.
Returns the attributes of the file after the write has
taken place
Changes the name of file name in directory dirfh to
toname in directory todirfh
Creates an entry newname in the directory newdirfh
which refers to file name in the directory dirfh
Creates an entry newname in the directory newdirfh
of type symbolic link with the value string. The
server does not interpret the string but makes a
symbolic link file to hold it
Returns the string that is associated with the
symbolic link file identified by fh
Creates a new directory name with attributes attr and
returns the new file handle and attributes
Removes the empty directory name from the parent
directory dirfh. Fails if the directory is not empty

23-Apr-15 10:02 PM

Distributed File Systems

4 of 4

http://www.csc.villanova.edu/~huliu/ds/CH8.html

readdir (dirfh, cookie,

count)

entries

statfs (fh)

fsstats

Returns up to count bytes of directory entries from

the directory dirfh. Each entry contains a file name,
a file handle, and an opaque pointer to the next
directory entry, called a cookie. The cookie is used in
subsequent readdir calls to start reading from the
following entry. If the value of cookie is 0, reads
from the first entry in the directory
Returns file system information (such as block size,
number of free blocks and so on) for the file system
containing a file fh

a. Virtual file system resides in each local computer to distinguish local files from remote files and
correspondingly connects to either Unix file system if the file is stored in the local computer or
NFS client otherwise. This way, the system is transparent to users: all files look like stored in the
local machine.
b. Access control. Each file access is verified by the server, different from conventional Unix file
system where access permission is verified at the open() operation.
c. NFS server interface. The RPC (remote procedure call, using either UDP or TCP) interface is
included in table 2. The file access operations read(), write(), getattr(), setattr()
are almost identical to the corresponding abstract operations defined the above architecture.
d. Server/client Caching. Caching in both the client and the server computers are indispensable
features of NFS implementations in order to achieve adequate performance.
e. Security. The Kerberos authentication system is used to secure the NFS.

23-Apr-15 10:02 PM