6/5/2024

Storage Models
2

Distributed File System

CHAPTER 12
SLIDES BA SED ON COULOURIS INSTRUCTOR MA TERIAL,
Manual file
BINA’S NOTES; CLIENT/SERVER MATERIAL BASED ON
Centralized Distributed Decentralized
K.BIR M A N’S OF COR NELL, system –
DUSSEU’S OF WISCONSIN
paper ledgers file system file system file system

CSE4/587 B. Ramamurthy 6/5/2024

Computing Evolution Traditional Storage Solutions

3 4
Data size: small
Pipelined Instruction level

Concurrent Thread level Off system/online

File system
storage/ Offline/ tertiary
abstraction/
Service Object level secondary memory/ DFS
Databases
memory
Indexed File level

Mega Block level RAID: Redundant

NAS: Network SAN: Storage area
Array of
Virtual System Level Accessible Storage networks
Inexpensive Disks
Data size: large

CSE4/587 B. Ramamurthy 6/5/2024 cse4/587 6/5/2024

What is a DFS? File system modules

5

 A DFS enables programs to store and access remote files /storage

exactly as they do local ones. Direc tory module: relates file names to file IDs
 The performance and reliability of such access should be comparable to File module: relates file IDs to particular files
that for files stored locally. Access control module: checks permission for operation requested
 Recent advances in higher bandwidth connectivity of switched local File access module: reads or w rites file data or attributes
networks and disk organization have lead high performance and Block module: acc esses and allocates dis k blocks
highly scalable file systems. Device module: disk I/O and buffering
 Functional requirements: open, close, read, write, access control,
directory organization, .. Best practice #1: When designing systems think in terms of modules of functionality.

 Non-functional requirements: scalable, fault-tolerant, secure,

cse4/587 6/5/2024 Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012

1
 6/5/2024

File attribute record structure UNIX file system operations

8

File length
filedes = open(name, mode) Opens an existing file with the given name.
Creation timestamp filedes = creat(name, mode) Creates a new file with the given name.
Read timestamp Both operations deliver a file descriptor referencing the open
file. The mode is read, write or both.
Write timestamp status = close(filedes) Closes the open file filedes.
Attribute timestamp count = read(filedes, buffer, n) Transfers n bytes from the file referenced by filedes to buffer.
Reference count 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
Owner and advance the read-write pointer.
pos = lseek(filedes, offset, Moves the read-write pointer to offset (relative or absolute,
File type whence) depending on whence).
Access control list 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.

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

Distributed File System Requirements Transparency

9 10

 Many of the requirements of distributed services were lessons learned  Access transparency: Client programs should be unaware of the distribution
of files.
from distributed file service.  Location transparency: Client program should see a uniform namespace.
 First needs were: access transparency and location transparency. Files should be able to be relocated without changing their path name.
 Symbolic links
 Later on, performance, scalability, concurrency control, fault tolerance  Cygwin is an example of unix like interface to Windows; it uses symbolic links extensively.

and security requirements emerged and were met in the later phases of  Symbolic links

DFS development. castor> ln -s dir link

castor> ls link
 Distributed file system is implemented using client/server model. file1 file2 file3 file4
castor> ls -l link
lrwxrwxrwx 1 user 7 Jan 11 23:27 link -> dir
.

Transparency Other Requirements

11 12

 Mobility transparency: Neither client programs  Concurrent file updates is protected (record locking).
nor system admin program tables in the client  File replication to allow performance.
nodes should be changed when files are moved  Hardware and operating system heterogeneity.
either automatically or by the system admin.  Fault tolerance
 Performance transparency: Client programs  Consistency : Unix uses on-copy update semantics. This
should continue to perform well on load within a may be difficult to achieve in DFS.
specified range.  Security
 Efficiency
 Scaling transparency: increase in size of storage
and network size should be transparent

2
 6/5/2024

General File Service Architecture File service architecture model

13 14

 The responsibilities of a DFS are typically distributed among three Client computer Server computer
modules:
Directory service
 Client module which emulates the conventional file system interface Application Application
program program
 Server modules(2) which perform operations for clients on directories and on
files.
 Most importantly this architecture enables stateless implementation of the Flat file service
server modules. Client module

 Our approach to design of distributed system: architecture, API, protocols,

implementation

Best Practice#2: An architecture model.. To discuss your design; clearly articulates the client/server aspect.

Flat file service Interface Directory service Interface

15 16

Read(FileId, i, n) -> Data If 1 ≤ i ≤ Length(File): Reads a sequence of up to n items Lookup(Dir, Name) -> FileId Locates the text name in the directory and returns the
— throwsBadPosition from a file starting at item i and returns it in Data. — throwsNotFound relevant UFID. If Name is not in the directory, throws an
exception.
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. 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.
Create() -> FileId Creates a new file of length 0 and delivers a UFID for it. If Name is already in the directory: throws an exception.
Delete(FileId) Removes the file from the file store. UnName(Dir, Name) If Name is in the directory: the entry containing Name is
GetAttributes(FileId) -> AttrReturns the file attributes for the file. — throwsNotFound removed from the directory.
If Name is not in the directory: throws an exception.
SetAttributes(FileId, Attr) Sets the file attributes (only those attributes that are not GetNames(Dir, Pattern) -> NameSeqReturns all the text names in the directory that match the
shaded in ). regular expression Pattern.

Primary operations are reading and writing. Primary purpose is to provide a service for translation
What’s missing? How about Open and Close? text names to UFIDs.

Network File System NFS architecture

17 18

 The Network File System (NFS) was developed to allow machines to Client computer Server computer

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. Application Application
program program
UNIX
system calls
UNIX kernel
UNIX kernel Virtual file system Virtual file system
Local Remote
file system

UNIX NFS NFS UNIX

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.

3
 6/5/2024

NFS server operations (simplified) – 1 NFS server operations (simplified) – 2

19 20

lookup(dirfh, name) -> fh, attr Returns file handle and attributes for the file name in the directory symlink(newdirfh, newname, string) Creates an entry newname in the directory newdirfh of type
dirfh. -> status symbolic link with the value string. The server does not interpret
create(dirfh, name, attr) -> Creates a new file name in directory dirfh with attributes attr and the string but makes a symbolic link file to hold it.
newfh, attr returns the new file handle and attributes.
readlink(fh) -> string Returns the string that is associated with the symbolic link file
remove(dirfh, name) status Removes file name from directory dirfh. identified by fh.
getattr(fh) -> attr Returns file attributes of file fh. (Similar to the UNIX stat system mkdir(dirfh, name, attr) -> Creates a new directory name with attributes attr and returns the
call.) newfh, attr new file handle and attributes.
setattr(fh, attr) -> attr Sets the attributes (mode, user id, group id, size, access time rmdir(dirfh, name) -> status Removes the empty directory name from the parent directory dirfh.
modify time of a file). Setting the size to 0 truncates the file.
and Fails if the directory is not empty.
read(fh, offset, count) -> attr, data Returns up to count bytes of data from a file starting at offset.
readdir(dirfh, cookie, count) -> Returns up to count bytes of directory entries from the directory
Also returns the latest attributes of the file. entries dirfh. Each entry contains a file name, a file handle, and an opaque
write(fh, offset, count, data) -> attr Writes count bytes of data to a file starting at offset. Returns the pointer to the next directory entry, called a cookie. The cookie is
attributes of the file after the write has taken place. used in subsequent readdir calls to start reading from the following
rename(dirfh, name, todirfh, toname)Changes the name of file name in directory dirfh to toname in entry. If the value of cookie is 0, reads from the first entry in the
-> status directory to todirfh
. directory.
link(newdirfh, newname, dirfh, name)Creates an entry newname in the directory newdirfh which refers to statfs(fh) -> fsstats Returns file system information (such as block size, number of
-> status file name in the directory dirfh. free blocks and so on) for the file system containing a file fh.
Continues on next slide ...

NFS Overview Mapping UNIX System Calls to NFS Operations

 Remote Procedure Calls (RPC) for communication between client and server  Unix system call: fd = open(“/dir/foo”)
 Traverse pathname to get filehandle for foo
 Client Implementation
 dirfh = lookup(rootdirfh, “dir”);
 Provides transparent access to NFS file system  fh = lookup(dirfh, “foo”);
 UNIX contains Virtual File system layer (VFS)  Record mapping from fd file descriptor to fh NFS filehandle
 Vnode: interface for procedures on an individual file  Set initial file offset to 0 for fd
 Translates vnode operations to NFS RPCs  Return fd file descriptor
 Server Implementation  Unix system call: read(fd,buffer,bytes)
 Stateless: Must not have anything only in memory  Get current file offset for fd
 Map fd to fh NFS filehandle
 Implication: All modified data written to stable storage before return control to client
 Call data = read(fh, offset, bytes) and copy data into buffer
 Servers often add NVRAM to improve performance
 Increment file offset by bytes
 Next slides  Unix system call: close(fd)
 Free resources assocatiated with fd
Best Practice#4: Clearly define the functions with code examples/pseudo code

Client-side Caching Cache Consistency

 Caching needed to improve performance  Problem: Consistency across multiple copies (server and multiple
 Reads: Check local cache before going to server clients)
 Writes: Only periodically write-back data to server  How to keep data consistent between client and server?
 Avoid contacting server  If file is changed on server, will client see update?
 Avoid slow communication over network  Determining factor: Read policy on clients
 Server becomes scalability bottleneck with more clients
 How to keep data consistent across clients?
 Two client caches
 If write file on client A and read on client B, will B see update?
 data blocks
 Determining factor: Write and read policy on clients
 attributes (metadata)

Best Practice#5: Use caching to help performance.

4
 6/5/2024

NFS Consistency: Reads NFS Consistency: Writes

 Reads: How does client keep current with server state?
 Attribute cache: Used to determine when file changes  Writes: How does client update server?
 File open: Client checks server to see if attributes have changed  Files
 If haven’t checked in past T seconds (configurable, Ex: T=3)  Write-back from client cache to server every 30 seconds
 Discard entries every N seconds (configurable, Ex: N=60)  Also, Flush on close()
 Data cache  Directories
 Discard all blocks of file if attributes show file has been modified  Synchronously write to server
 Eg: Client cache has file A’s attributes and blocks 1, 2, 3  Example: Client X and Y have file A (blocks 1,2,3) cached
 Client opens A:  Clients X and Y open file A
 Client reads block 1
 Client X writes to blocks 1 and 2
 Client waits 70 seconds
 Client Y reads block 1
 Client reads block 2
 30 seconds later...
 Block 3 is changed on server
 Client reads block 3  Client Y reads block 2

 Client reads block 4  40 seconds later...

 Client waits 70 seconds  Client Y reads block 1
 Client reads block 1

NFS Architecture NFS Protocol

27 28

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

 One of the goals of NFS is to support a heterogeneous system,
file system.
with clients and servers running different operating systems on
 In many cases all servers and clients are on the same LAN but this is not different hardware. It is essential the interface between clients
required. and server be well defined.
 NFS allows every machine to be a client and server at the same time.  NFS accomplishes this goal by defining two client-server
protocol: one for handling mounting and another for directory
 Each NFS server exports one or more directories for access by remote
and file access.
clients.
 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 Mounting

30

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

Server 1 Client Server 2
(root)
the server returns file handle to the client.
(root) (root)
 Or the mounting can be automatic by placing the directories to
mounted in the /etc/rc: automounting.
export ... vmunix usr nf s

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

5
 6/5/2024

File Access Implementation

31 32

 NFS supports most unix operations except open and close. This is to  After the usual system call layer, NFS specific layer Virtual File System
satisfy the “statelessness” on the server end. Server need not keep a list (VFS) maintains an entry per file called vnode (virtual I-node) for every
of open connections. (On the other hand consider your database open file.
connection… you create an object, connection is opened etc.)  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 Remote File Access

33 34

 To mount a remote file system, the sys admin (or /etc/rc)  When a remote file is opened by the client, it locates the r-
calls the mount program specifying the remote directory, node.
local directory in which to be mounted, and other info.  It then asks NFS Client to open the file. NFS file looks up
 If the remote directory exist and is available for mounting, the path in the remote file system and return the file handle
mount system call is made. to VFS tables.
 Kernel constructs vnode for the remote directory and asks the  The caller (application) is given a file descriptor for the
NFS-client code to create a r-node (remote I-node) in its remote file. No table entries are made on the server side.
internal tables. V-node in the client VFS will point to local I-  Subsequent reads will invoke the remote file, and for
node or this r-node. efficiency sake the transfers are usually in large chunks (8K).

Server Side of File Access Summary

35

 When the request message arrives at the NFS server, it is passed to the  Distributed file systems
VFS layer where the file is probably identified to be a local or remote file.  Important for data sharing
 Challenges: Fault tolerance, scalable performance, and consistency
 Usually a 8K chunk is returned. Read ahead and caching are used to
improve efficiency.  NFS: Popular distributed file system
 Key features:
 Cache: server side for disk accesses, client side for I-nodes and another for  Stateless server, idempotent operations: Simplifies fault tolerance
file data.  Crashed server appears as slow server to clients
 Of course this leads to cache consistency and security problem which ties  Client caches needed for scalable performance
us into other topics we are discussing.  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.