Distributed File System

Storage Models
2

Manual file
Decentraliz
system – Centralized Distributed
ed file
paper file system file system
system
ledgers

05/15/2025
 Computing Evolution
3
Data size: small
• Single-core, single processor
Single
Pipelined Instruction level • Single-core, multi-processor
-core
• Multi-core, single processor
Multi-
Concurrent Thread level • Multi-core, multi-processor
core • Cluster of processors (single or multi-core)
with shared memory
Service Object level Cluster • Cluster of processors with distributed
memory

Indexed File level Grid of clusters

Mega Block level Embarrassingly

parallel processing
Virtual System Level MapReduce, distributed
file system
Data size: large
Cloud computing: google,
box, aws S3

05/15/2025
 Traditional Storage Solutions
4

Off
system/online File system
Offline/ tertiary
storage/ abstraction/
memory/ DFS
secondary Databases
memory
RAID:
Redundant NAS: Network
SAN: Storage
Array of Accessible
area networks
Inexpensive Storage
Disks

05/15/2025
 What is a DFS?
5

A DFS enables programs to store and access remote files

/storage exactly as they do 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,

05/15/2025
 File system modules

Directory module: relates file names to file IDs

File module: relates file IDs to particular files

Access control module: checks permission for operation requested

File access module: reads or writes file data or attributes

Block module: accesses and allocates disk blocks

Device module: disk I/O and buffering

Best practice #1: When designing systems think in terms of modules of functionality.
File attribute record structure

File length
Creation timestamp
Read timestamp
Write timestamp
Attribute timestamp
Reference count
Owner
File type
Access control list
 UNIX file system operations
8

filedes = open(name, mode) Opens an existing file with the given name.
filedes = creat(name, mode) Creates a new file with the given name.
Both operations deliver a file descriptor referencing the open
file. The mode is read, write or both.
status = close(filedes) Closes the open file filedes.
count = read(filedes, buffer, n) Transfers n bytes from the file referenced by filedes to buffer.
count = write(filedes, buffer, n) Transfers n bytes to the file referenced by filedes from buffer.
Both operations deliver the number of bytes actually transferred
and advance the read-write pointer.
pos = lseek(filedes, offset, Moves the read-write pointer to offset (relative or absolute,
whence) depending on whence).
status = unlink(name) Removes the file name from the directory structure. If the file
has no other names, it is deleted.
status = link(name1, name2) Adds a new name (name2) for a file (name1).
status = stat(name, buffer) Gets the file attributes for file name into buffer.
 Distributed File System Requirements
9

Many of the requirements of distributed services were lessons

learned from distributed file service.
First needs were: access transparency and location
transparency.
Later on, performance, scalability, concurrency control, fault
tolerance and security requirements emerged and were met
in the later phases of DFS development.
Distributed file system is implemented using client/server
model.
 Transparency
10

 Access transparency: Client programs should be unaware of the

distribution of files.
 Location transparency: Client program should see a uniform
namespace. Files should be able to be relocated without changing
their path name.
 Symbolic links
 Cygwin is an example of unix like interface to Windows; it uses symbolic links
extensively.
 Symbolic links
castor> ln -s dir link
castor> ls link
file1 file2 file3 file4
castor> ls -l link
lrwxrwxrwx 1 user 7 Jan 11 23:27 link -> dir
.
 Transparency
11

Mobility transparency: Neither client

programs nor system admin program tables
in the client nodes should be changed when
files are moved either automatically or by
the system admin.
Performance transparency: Client
programs should continue to perform well
on load within a specified range.
Scaling transparency: increase in size of
storage and network size should be
transparent
 Other Requirements
12

Concurrent file updates is protected (record

locking).
File replication to allow performance.
Hardware and operating system heterogeneity.
Fault tolerance
Consistency : Unix uses on-copy update semantics.
This may be difficult to achieve in DFS.
Security
Efficiency
 General File Service Architecture
13

The responsibilities of a DFS are typically distributed among

three modules:
 Client module which emulates the conventional file system interface
 Server modules(2) which perform operations for clients on directories
and on files.
Most importantly this architecture enables stateless
implementation of the server modules.
Our approach to design of distributed system: architecture, API,
protocols, implementation
 File service architecture model
14

Client computer Server computer

Application Application Directory service

program program

Flat file service

Client module

st Practice#2: An architecture model.. To discuss your design; clearly articulates the client/server aspect.
 Flat file service Interface
15

Read(FileId, i, n) -> Data If 1 ≤ i ≤ Length(File): Reads a sequence of up to n items

— throwsBadPosition from a file starting at item i and returns it in Data.
Write(FileId, i, Data) If 1 ≤ i ≤ Length(File)+1: Writes a sequence of Data to a
— throwsBadPosition file, starting at item i, extending the file if necessary.
Create() -> FileId Creates a new file of length 0 and delivers a UFID for it.
Delete(FileId) Removes the file from the file store.
GetAttributes(FileId) -> AttrReturns the file attributes for the file.
SetAttributes(FileId, Attr) Sets the file attributes (only those attributes that are not
shaded in ).

Primary operations are reading and writing.

What’s missing? How about Open and Close?
 Directory service Interface
16

Lookup(Dir, Name) -> FileId Locates the text name in the directory and returns the
— throwsNotFound relevant UFID. If Name is not in the directory, throws an
exception.
AddName(Dir, Name, File) If Name is not in the directory, adds (Name, File) to the
— throwsNameDuplicate directory and updates the file’s attribute record.
If Name is already in the directory: throws an exception.
UnName(Dir, Name) If Name is in the directory: the entry containing Name is
— throwsNotFound removed from the directory.
If Name is not in the directory: throws an exception.
GetNames(Dir, Pattern) -> NameSeq Returns all the text names in the directory that match the
regular expression Pattern.

Primary purpose is to provide a service for translation

text names to UFIDs.
 Network File System
17

The Network File System (NFS) was developed to allow

machines to mount a disk partition on a remote machine as if
it were on a local hard drive. This allows for fast, seamless
sharing of files across a network.
 NFS architecture
18

Client computer Server computer

Application Application
program program
UNIX
system calls
UNIX kernel
UNIX kernel Virtual file system Virtual file system
Local Remote

UNIX file system UNIX

NFS NFS
file file
Other

client server
system system
NFS
protocol

Best Practice #3: Symmetry in design; you have a client as well as a server module for the VFS/DFS.
NFS server operations (simplified) – 1
19

lookup(dirfh, name) -> fh, attr Returns file handle and attributes for the file name in the directory
dirfh.
create(dirfh, name, attr) -> Creates a new file name in directory dirfh with attributes attr and
newfh, attr returns the new file handle and attributes.
remove(dirfh, name) status Removes file name from directory dirfh.
getattr(fh) -> attr Returns file attributes of file fh. (Similar to the UNIX stat system
call.)
setattr(fh, attr) -> attr Sets the attributes (mode, user id, group id, size, access time
modify time of a file). Setting the size to 0 truncates the file.
and
read(fh, offset, count) -> attr, data Returns up to count bytes of data from a file starting at offset.
Also returns the latest attributes of the file.
write(fh, offset, count, data) -> attr Writes count bytes of data to a file starting at offset. Returns the
attributes of the file after the write has taken place.
rename(dirfh, name, todirfh, toname)Changes the name of file name in directory dirfh to toname in
-> status directory to todirfh
.
link(newdirfh, newname, dirfh, name)Creates an entry newname in the directory newdirfh which refers to
-> status file name in the directory dirfh.
Continues on next slide ...
 NFS server operations (simplified) – 2
20

symlink(newdirfh, newname, string) Creates an entry newname in the directory newdirfh of type
-> status symbolic link with the value string. The server does not interpret
the string but makes a symbolic link file to hold it.
readlink(fh) -> string Returns the string that is associated with the symbolic link file
identified by fh.
mkdir(dirfh, name, attr) -> Creates a new directory name with attributes attr and returns the
newfh, attr new file handle and attributes.
rmdir(dirfh, name) -> status Removes the empty directory name from the parent directory dirfh.
Fails if the directory is not empty.
readdir(dirfh, cookie, count) -> Returns up to count bytes of directory entries from the directory
entries 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.
statfs(fh) -> fsstats Returns file system information (such as block size, number of
free blocks and so on) for the file system containing a file fh.
 NFS Overview

 Remote Procedure Calls (RPC) for communication between client and

server
 Client Implementation
 Provides transparent access to NFS file system
 UNIX contains Virtual File system layer (VFS)
 Vnode: interface for procedures on an individual file
 Translates vnode operations to NFS RPCs
 Server Implementation
 Stateless: Must not have anything only in memory
 Implication: All modified data written to stable storage before return control to
client
 Servers often add NVRAM to improve performance

 Next slides
Best Practice#4: Clearly define the functions with code examples/pseudo code
 Client-side Caching

Caching needed to improve performance

 Reads: Check local cache before going to server
 Writes: Only periodically write-back data to server
 Avoid contacting server
 Avoid slow communication over network
 Server becomes scalability bottleneck with more clients
Two client caches
 data blocks
 attributes (metadata)

Best Practice#5: Use caching to help performance.

 Cache Consistency

Problem: Consistency across multiple copies (server and

multiple clients)
 How to keep data consistent between client and server?
 If file is changed on server, will client see update?
 Determining factor: Read policy on clients

 How to keep data consistent across clients?

 If write file on client A and read on client B, will B see update?
 Determining factor: Write and read policy on clients
 NFS Consistency: Reads
 Reads: How does client keep current with server state?
 Attribute cache: Used to determine when file changes
 File open: Client checks server to see if attributes have changed
 If haven’t checked in past T seconds (configurable, Ex: T=3)
 Discard entries every N seconds (configurable, Ex: N=60)
 Data cache
 Discard all blocks of file if attributes show file has been modified
 Eg: Client cache has file A’s attributes and blocks 1, 2, 3
 Client opens A:
 Client reads block 1
 Client waits 70 seconds
 Client reads block 2
 Block 3 is changed on server
 Client reads block 3
 Client reads block 4
 Client waits 70 seconds
 Client reads block 1
 NFS Consistency: Writes

 Writes: How does client update server?

 Files
 Write-back from client cache to server every 30 seconds
 Also, Flush on close()
 Directories
 Synchronously write to server
 Example: Client X and Y have file A (blocks 1,2,3) cached
 Clients X and Y open file A
 Client X writes to blocks 1 and 2
 Client Y reads block 1
 30 seconds later...
 Client Y reads block 2
 40 seconds later...
 Client Y reads block 1
 NFS Architecture
26

Allows an arbitrary collection of clients and servers to share a

common file system.
In many cases all servers and clients are on the same LAN but
this is not required.
NFS allows every machine to be a client and server at the
same time.
Each NFS server exports one or more directories for access
by remote clients.
 NFS Protocol
27

One of the goals of NFS is to support a heterogeneous

system, with clients and servers running different
operating systems on different hardware. It is essential
the interface between clients and server be well
defined.
NFS accomplishes this goal by defining two client-
server protocol: one for handling mounting and another
for directory and file access.
Protocol defines requests by clients and responses by
servers.
Best practice #6: After architecture model define a
protocol or collection of general rules for operation.
Local and remote file systems accessible on an NFS
client

Server 1 Client Server 2

(root) (root) (root)

export ... vmunix usr nfs

Remote Remote
people students x staff users
mount mount

big jon bob ... jim ann jane joe

Note: 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.

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
 Mounting
29

Client requests a directory structure to be mounted, if the

path is legal the server returns file handle to the client.
Or the mounting can be automatic by placing the directories
to mounted in the /etc/rc: automounting.
 File Access
30

NFS supports most unix operations except open and close.

This is to satisfy the “statelessness” on the server end. Server
need not keep a list of open connections. (On the other hand
consider your database connection… you create an object,
connection is opened etc.)
 Implementation
31

After the usual system call layer, NFS specific layer Virtual
File System (VFS) maintains an entry per file called vnode
(virtual I-node) for every open file.
Vnode indicate whether a file is local or remote.
 For remote files extra info is provided.
 For local file, file system and I-node are specified.
 Lets see how to use v-nodes using a mount, open, read system calls from a
client application.
 Vnode use
32

To mount a remote file system, the sys admin (or

/etc/rc) calls the mount program specifying the
remote directory, local directory in which to be
mounted, and other info.
If the remote directory exist and is available for
mounting, mount system call is made.
Kernel constructs vnode for the remote directory and
asks the NFS-client code to create a r-node (remote
I-node) in its internal tables. V-node in the client VFS
will point to local I-node or this r-node.
 Remote File Access
33

When a remote file is opened by the client, it locates

the r-node.
It then asks NFS Client to open the file. NFS file
looks up the path in the remote file system and
return the file handle to VFS tables.
The caller (application) is given a file descriptor for
the remote file. No table entries are made on the
server side.
Subsequent reads will invoke the remote file, and
for efficiency sake the transfers are usually in large
chunks (8K).
 Server Side of File Access
34

When the request message arrives at the NFS server, it is

passed to the VFS layer where the file is probably identified to
be a local or remote file.
Usually a 8K chunk is returned. Read ahead and caching are
used to improve efficiency.
Cache: server side for disk accesses, client side for I-nodes and
another for file data.
Of course this leads to cache consistency and security problem
which ties us into other topics we are discussing.
 Summary

 Distributed file systems

 Important for data sharing
 Challenges: Fault tolerance, scalable performance, and consistency

 NFS: Popular distributed file system

 Key features:
 Stateless server, idempotent operations: Simplifies fault tolerance
 Crashed server appears as slow server to clients
 Client caches needed for scalable performance
 Rules for invalidating cache entries and flushing data to server are not straight-forward
 Data consistency very hard to reason about
 Pay attention to best practices when designing systems. We discussed at least 6
general best practices that you could use in your design of projects.