Distributed file systems allow files to be accessed across a network in a transparent manner. They achieve high availability by allowing users easy access to files irrespective of physical location. A DFS uses name servers to map file names to storage locations and cache managers to copy remote files to clients for faster access. Key components include caching, replication for availability, and consistency protocols to ensure clients see up-to-date file data. Design goals involve scalability to large numbers of clients and servers as well as maintaining strong file semantics even in distributed systems.

1. Distributed File Systems (DFS)
A RESOURCE MANAGEMENT
COMPONENT OF A DISTRIBUTED
OPERATING SYSTEM

2. Achievements through DFS
 Two important goals of distributed file systems
 Network Transparency
 To provide the same functional capabilities to access files distributed over a network
 Users do not have to be aware of the location of files to access them
 High Availability
 Users should have the same easy access to files, irrespective of their physical
location
 System failures or regularly scheduled activities such as backups or maintenance
should not result in the unavailability of files

3. Architecture
 Files can be stored at any machine and computation can be
performed at any machine
 A machine can access a file stored on a remote machine where
the file access operations are performed and the data is returned
 Alternatively, File Servers are provided as dedicated to storing
files and performing storage and retrieval operations
 Two most important services in a DFS are
 Name Server: a process that maps names specified by clients
to stored objects, e.g. files and directories
 Cache Manager: a process that implements file caching, i.e.
copying a remote file to the client’s machine when referred by
the client

4. Architecture of DFS

5. Data Access Actions in DFS

6. Mechanisms for Building DFS
 Mounting
 Allows the binding together of different filename spaces to form a single
hierarchically structured name space
 Kernel maintains a structure called the mount table which maps mount
points to appropriate storage devices.
 Caching
 To reduce delays in the accessing of data by exploiting the temporal locality
of reference exhibited by program
 Hints
 An alternative to cached data to overcome inconsistency problem when
multiple clients access shared data
 Bulk Data Transfer
 To overcome the high cost of executing communication protocols, i.e.
assembly/disassembly of packets, copying of buffers between layers
 Encryption
 To enforce security in distributed systems with a scenario that two entities
wishing to communicate establish a key for conversation

7. Design Goals
 Naming and Name Resolution
 Caches on Disk or Main Memory
 Writing Policy
 Cache Consistency
 Availability
 Scalability
 Semantics

8. Naming and Name Resolution
 Name in file systems is associated with an object (e.g. a file or a directory)
 Name resolution refers to the process of mapping a name to an object, or in case
of replication, to multiple objects.
 Name space is a collection of names which may or may not share an identical
resolution mechanism
 Three approaches to name files in DE
 Concatenation
 Mounting (Sun NFS)
 Directory structured (Sprite and Apollo)
 The Concepts of Contexts
 A context identifies the name space in which to resolve a given name
 Examples: x-Kernel Logical File System, Tilde Naming Scheme
 Name Server
 Resolves the names in distributed systems. Drawbacks involved such as single
point of failure, performance bottleneck. Alternate is to have several name
servers, e.g. Domain Name Servers

9. Caches on Disk or Main Memory
 Cache in Main Memory
 Diskless workstations can also take advantage of caching
 Accessing a cache is much faster than access a cache on local disk
 The server-cache is in the main memory, and hence a single cache design for
both
 Disadvantages
 It competes with the virtual memory system for physical memory space
 A more complex cache manager and memory management system
 Large files cannot be cached completely in memory
 Cache in Local Disk
 Large files can be cached without affecting performance
 Virtual memory management is simple
 Example: Coda File System

10. Writing Policy
 Decision to when the modified cache block at a client should be
transferred to the server
 Write-through policy
 All writes requested by the applications at clients are also carried out at
the server immediately.
 Delayed writing policy
 Modifications due to a write are reflected at the server after some delay.
 Write on close policy
 The updating of the files at the server is not done until the file is closed

11. Cache Consistency
 Two approaches to guarantee that the data returned to the client
is valid.
 Server-initiated approach
 Server inform cache managers whenever the data in the client caches become
stale
 Cache managers at clients can then retrieve the new data or invalidate the
blocks containing the old data
 Client-initiated approach
 The responsibility of the cache managers at the clients to validate data with the
server before returning it
 Both are expensive since communication cost is high
 Concurrent-write sharing approach
 A file is open at multiple clients and at least one has it open for writing.
 When this occurs for a file, the file server informs all the clients to purge their
cached data items belonging to that file.
 Sequential-write sharing issues causing cache inconsistency
 Client opens a file, it may have outdated blocks in its cache
 Client opens a file, the current data block may still be in another client’s cache
waiting to be flushed. (e.g. happens in Delayed writing policy)

12. Availability
 Immunity to the failure of server of the communication network
 Replication is used for enhancing the availability of files at different
servers
 It is expensive because
 Extra storage space required
 The overhead incurred in maintaining all the replicas up to date
 Issues involve
 How to keep the replicas of a file consistent
 How to detect inconsistencies among replicas of a file and recover from these
inconsistencies
 Causes of Inconsistency
 A replica is not updated due to failure of server
 All the file servers are not reachable from all the clients due to network
partition
 The replicas of a file in different partitions are updated differently

13. Availability (contd.)
 Unit of Replication
 The most basic unit is a file
 A group of files of a single user or the files that are in a server
(the group file is referred to as volume, e.g. Coda)
 Combination of two techniques, as in Locus
 Replica Management
 The maintenance of replicas and in making use of them to
provide increased availability
 Concerns with the consistency among replicas
 A weighted voting scheme (e.g. Roe File System)
 Designated agents scheme (e.g. Locus)
 Backups servers scheme (e.g. Harp File System)

14. Scalability
 The suitability of the design of a system to cater to the demands
of a growing system
 As the system grow larger, both the size of the server state and
the load due to invalidations increase
 The structure of the server process also plays a major role in
deciding how many clients a server can support
 If the server is designed with a single process, then many clients have to
wait for a long time whenever a disk I/O is initiated
 These waits can be avoided if a separate process is assigned to each
client
 A significant overhead due to the frequent context switches to handle
requests from different clients can slow down the server
 An alternate is to use Lightweight processes (threads)

15. Semantics
 The semantics of a file system characterizes the effects of accesses on
files
 Guaranteeing the semantics in distributed file systems, which employ
caching, is difficult and expensive
 In server-initiated cache the invalidation may not occur immediately
after updates and before reads occur at clients.
 This is due to communication delays
 To guarantee the above semantics all the reads and writes from various
clients will have to go through the server
 Or sharing will have to be disallowed either by the server, or by the use
of locks by applications

16. Student’s Task
CASE STUDIES
9.5.1 THE SUN NETWORK FILE SYSTEM