Chapter 5: Distributed File Systems
description
Transcript of Chapter 5: Distributed File Systems
![Page 1: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/1.jpg)
1
Chapter 5:
Distributed File
Systems
![Page 2: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/2.jpg)
2
Distributed file system - enables programs to store/access remote files
- from any computer on a network. Performance & reliability experienced for access to files stored at a server:
- comparable to file stored on local disk. Basic distributed file service implementations: Sun Network File Systems (NFS) Andrew File System (AFS)
Introduction
![Page 3: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/3.jpg)
3
Storage systems and their properties
First generation of DS (1974-95):- file systems (e.g. NFS) - only networked storage systems.
Advent of distributed object systems (CORBA, Java) and the web
- file systems has become more complex.
Introduction (Cont).
![Page 4: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/4.jpg)
4
Fig. 8.1: Storage systems and their properties
Sharing Persis-tence
Distributedcache/replicas
Consistencymaintenance
Example
Main memory RAM
File system UNIX file system
Distributed file system Sun NFS
Web Web server
Distributed shared memory Ivy (DSM, Ch. 18)
Remote objects (RMI/ORB) CORBA
Persistent object store 1 CORBA PersistentObject Service
Peer-to-peer storage system OceanStore (Ch. 10)
1
1
1
2
Types of consistency between copies:1 - strict one-copy consistency√ - approximate consistency, slightly weaker guaranteesX - no automatic consistency2: considerably weaker guarantees
![Page 5: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/5.jpg)
5
What is a file system?Introduction (Cont).
Persistent stored data sets Hierarchic name space visible to all processes API with the following characteristics:
Share data between users, with access control - access and update operations on persistently
stored data sets - sequential access model (with additional random facilities)Concurrent access:-certainly for read-only accessOther features:
- mountable file stores
![Page 6: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/6.jpg)
6
Figure 8.2File 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
![Page 7: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/7.jpg)
7
updated by system:
What is a file system?
updated by owner:
Fig. 8.3: File attribute record structureFile length
Creation timestampRead timestampWrite timestamp
Attribute timestampReference count
OwnerFile type
Access control list
E.g. for UNIX: rw-rw-r--
![Page 8: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/8.jpg)
8
TranparenciesAccess: Same operationsLocation: Same name space after relocation
of files or processesMobility: Automatic relocation of files is
possiblePerformance: Satisfactory performance across
a specified range of system loadsScaling: Service can be expanded to meet
additional loads
Concurrency propertiesIsolationFile-level or record-level lockingOther forms of concurrency control to minimise
contention
Replication propertiesFile service maintains multiple identical copies
of files• Load-sharing between servers makes
service more scalable• Local access has better response (lower
latency)• Fault toleranceFull replication is difficult to implement.Caching (of all or part of a file) gives most of
the benefits (except fault tolerance)
Heterogeneity propertiesService can be accessed by clients running on
(almost) any OS or hardware platform.Design must be compatible with the file
systems of different OSesService interfaces must be open - precise
specifications of APIs are published.
Fault toleranceService must continue to operate even when
clients make errors or crash.• at-most-once semantics• at-least-once semantics
• requires idempotent operations
Service must resume after a server machine crashes.
If the service is replicated, it can continue to operate even during a server crash.
ConsistencyUnix offers one-copy update semantics for
operations on local files - caching is completely transparent.
Difficult to achieve the same for distributed file systems while maintaining good performance and scalability.
SecurityMust maintain access control and privacy as
for local files.• based on identity of user making request• identities of remote users must be
authenticated• privacy requires secure communication
Service interfaces are open to all processes not excluded by a firewall.• vulnerable to impersonation and other
attacks
EfficiencyGoal for distributed file systems is usually
performance comparable to local file system.
Distributed File System Requirements
• Transparency• Concurrency• Replication• Heterogeneity• Fault tolerance• Consistency• Security• Efficiency..
![Page 9: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/9.jpg)
Distributed File System Requirements
• File system is the most heavily loaded service in internet, so its functionality and performance are critical.
• The design should support many transparencies• Access transparency: Clients should be unaware of distribution of
files, i.e., a single command should be used to access local and remote files.
• Location transparency: Clients should see the same name space of a file irrespective of its location.
• Mobility transparency: Change in location of file should not affect user. Change should automatically be detected by administration tables.
• Performance transparency: Performance of the client should be satisfactory, when load varies on the service.
• Scaling transparency: service should be extendable to deal with a wide range of loads. 9
![Page 10: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/10.jpg)
File Service Architecture• A file service architecture has three divisions of
responsibilities:Flat file service: Concerned with the implementing
operations on the contents of the file. UFIDs (Unique File Identifies) are used to refer to files. UFIDs also differentiate between directory and file.
Directory Service: For mapping between text names of files and their UFIDs.
Client Module: A client module runs in each client computer . It integrates and extends operations of flat file service and directory service under a single interface. 10
![Page 11: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/11.jpg)
11
Fig. 8.5:Model File Service Architecture
Client computer Server computer
Applicationprogram
Applicationprogram
Client module
Flat file service
Directory service
LookupAddNameUnNameGetNames
ReadWriteCreateDeleteGetAttributesSetAttributes
![Page 12: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/12.jpg)
12
FileId
A unique identifier for files anywhere in the network.
Server Operations For The Model File Service
Flat file service
Read(FileId, i, n) -> Data
Write(FileId, i, Data)Create() -> FileIdDelete(FileId)
GetAttributes(FileId) -
> Attr
SetAttributes(FileId,
Attr)
Directory service
Lookup(Dir, Name) ->
FileId
AddName(Dir, Name,
File)
UnName(Dir, Name)
GetNames(Dir, Pattern) -
> NameSeq
Pathname lookupPathnames such as '/usr/bin/tar' are
resolved by iterative calls to lookup(), a call for each component of the path, starting with the ID of the root directory '/' which is known in every client.
position of first byte
position of first byte
Fig. 8.6 and 8.7
FileId
![Page 13: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/13.jpg)
13
File Group A collection of files that can be located on any server or moved between servers while maintaining the same names. A file can not change its group.– Similar to a UNIX filesystem – Helps with distributing the load of file
serving between several servers.– File groups have identifiers which are
unique throughout the system (and hence for an open system, they must be globally unique). • Used to refer to file groups and files
![Page 14: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/14.jpg)
14
To construct a globally unique ID we use some unique attribute of the
machine on which it is created, e.g. IP number, even though the file group
may move subsequently.
IP address date
32 bits 16 bits
File Group ID:
File Group (Cont.)
![Page 15: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/15.jpg)
15
Case Study: Sun NFS An industry standard for file sharing on local networks since the 1980s. Open standard with clear & simple interfaces. Supports many of the design requirements already mentioned:
- Transparency - Heterogeneity- Efficiency - Fault tolerance
Limited achievement of:- Concurrency - Replication- Consistency - Security
![Page 16: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/16.jpg)
16
Fig. 8.8: NFS Architecture
Client computer Server computer
UNIXfile
system
NFSclient
NFSserver
UNIXfile
system
Applicationprogram
Applicationprogram
Virtual file systemVirtual file system
Oth
er fi
le s
yste
m
UNIX kernel
system calls
NFSprotocol
(remote operations)
UNIX
Operations on local files
Operationson
remote files
Applicationprogram
NFSClient
KernelApplicationprogram
NFSClient
Client computer
![Page 17: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/17.jpg)
17
NFS architecture: does implementation have to be in
system kernel?No:
– there are examples of NFS clients and servers that run at application-level as libraries or processes (e.g. early Windows and MacOS implementations, current PocketPC, etc.)
Continues on next slide ...
![Page 18: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/18.jpg)
18
But, for a Unix implementation there are advantages:– Binary code compatible - no need to recompile
applications• Standard system calls that access remote files can
be routed through the NFS client module by the kernel
– Shared cache of recently-used blocks at client– Kernel-level server can access i-nodes and file
blocks directly• but a privileged (root) application program could do
almost the same.– Security of the encryption key used for
authentication.
![Page 19: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/19.jpg)
19
Fig. 8.9: NFS server operations (simplified) – 1
lookup(dirfh, name) -> fh, attr Returns file handle and attributes for the file name in the directory dirfh.
create(dirfh, name, attr) -> newfh, attr
Creates a new file name in directory dirfh with attributes attr andreturns 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 attributes (mode, user id, group id, size, access time &
modify time of a file). Setting the size to 0 truncates the file.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)
-> statusChanges the name of file name in directory dirfh to toname indirectory to todirfh.
link(newdirfh, newname, dirfh, name) -> status
Creates an entry newname in the directory newdirfh whichrefers to file name in the directory dirfh.
Continues on next slide ...
![Page 20: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/20.jpg)
20
Fig. 8.9: NFS server operations (simplified) – 2
symlink(newdirfh, newname, string)-> status
Creates an entry newname in the directory newdirfh of typesymbolic link with the value string. The server does not interpretthe string but makes a symbolic link file to hold it.
readlink(fh) -> string Returns the string that is associated with the symbolic link fileidentified by fh.
mkdir(dirfh, name, attr) -> newfh, attr
Creates a new directory name with attributes attr and returns thenew 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) -> entries
Returns up to count bytes of directory entries from the directorydirfh. Each entry contains a file name, a file handle, and an opaque
pointer to the next directory entry, called a cookie. The cookie isused in subsequent readdir calls to start reading from the following
entry. If the value of cookie is 0, reads from the first entry in thedirectory.
statfs(fh) -> fsstats Returns file system information (such as block size, number offree blocks and so on) for the file system containing a file fh.
![Page 21: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/21.jpg)
21
NFS Access Control & Authentication
Stateless server- user's identity & access rights must be checked by server on each request.-In local file system, checked only on open()
Every client request is accompanied by the userID and groupID. Server is exposed to imposter attacks unless userID & groupID are protected by encryption.Kerberos - integrated with NFS to provide a stronger & comprehensive security solution.
![Page 22: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/22.jpg)
22
Mount service Mount operation:mount(remotehost, remotedirectory,
localdirectory)
Server maintains a table of clients who have mounted filesystems at that
serverEach client maintains a table of
mounted file systems holding: < IP address, port number, file handle>
![Page 23: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/23.jpg)
23
Fig. 8.10: Local & remote file systems accessible on NFS
client
jim jane joeann
usersstudents
usrvmunix
Client Server 2
. . . nfs
Remote
mountstaff
big bobjon
people
Server 1
export
(root)
Remote
mount
. . .
x
(root) (root)
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.
![Page 24: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/24.jpg)
26
NFS Optimization - Server Caching
Similar to UNIX file caching for local files:– pages (blocks) from disk are held in a main memory
buffer cache until the space is required for newer pages. Read-ahead and delayed-write optimizations.
– For local files, writes are deferred to next sync event (30 second intervals)
– Works well in local context, where files are always accessed through the local cache, but in the remote case it doesn't offer necessary synchronization guarantees to clients.
![Page 25: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/25.jpg)
27
NFS v3 servers offers two strategies for updating the disk:– write-through - altered pages are written to disk as
soon as they are received at the server. When a write() RPC returns, the NFS client knows that the page is on the disk: non pre-emptive
– delayed commit - pages are held only in the cache until a commit() call is received for the relevant file. This is the default mode used by NFS v3 clients. A commit() is issued by the client whenever a file is closed: pre-emptive
NFS Optimization - Server Caching (Cont.)
![Page 26: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/26.jpg)
28
NFS Optimization - Client Caching
Server caching does nothing to reduce RPC traffic between client and server– further optimization is essential to reduce server load
in large networks– NFS client module caches the results of read, write,
getattr, lookup and readdir operations– synchronization of file contents (one-copy semantics)
is not guaranteed when two or more clients are sharing the same file.
![Page 27: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/27.jpg)
29
NFS optimization - client caching (Cont.)Timestamp-based validity check
– reduces inconsistency, but doesn't eliminate it– validity condition for cache entries at the client:
(T - Tc < t) v (Tmclient = Tmserver)– t is configurable (per file) but is typically set to
3 seconds for files and 30 secs. for directories– it remains difficult to write distributed
applications that share files with NFS
t freshness guaranteeTc time when cache entry was last validatedTm time when block was last updated at serverT current time
![Page 28: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/28.jpg)
30
Other NFS optimizations Sun RPC runs over UDP by default (can use
TCP if required) Uses UNIX BSD Fast File System with 8-kbyte
blocks reads() and writes() can be of any size
(negotiated between client and server) the guaranteed freshness interval t is set
adaptively for individual files to reduce gettattr() calls needed to update Tm
file attribute information (including Tm) is piggybacked in replies to all file requests
![Page 29: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/29.jpg)
32
NFS Summary An excellent example of a simple, robust, high-
performance distributed service.
Achievement of transparencies: Access: Excellent; the API is the UNIX
system call interface for both local and remote files.Location: Not guaranteed but normally
achieved; naming of filesystems is controlled by client mount operations, but transparency can be ensured by an appropriate system configuration.
![Page 30: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/30.jpg)
33
Achievement of transparencies (continued):
Concurrency: Limited but adequate for most purposes; when read-write files are shared concurrently between clients, consistency is not perfect.
Replication: Limited to read-only file systems; for writable files, SUN Network Information Service (NIS) runs over NFS & is used to replicate essential system files.
Failure: Limited but effective; service is suspended if a server fails. Recovery from failures is aided by the simple stateless design.
![Page 31: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/31.jpg)
34
Achievement of transparencies (continued):
Mobility: Hardly achieved; relocation of files is not possible, relocation of filesystems is possible, but requires updates to client configurations.
Performance: Good; multiprocessor servers achieve very high performance, but for a single filesystem it's not possible to go beyond the throughput of a multiprocessor server.
Scaling: Good; filesystems (file groups) may be subdivided and allocated to separate servers. Ultimately, the performance limit is determined by the load on the server holding the most heavily-used filesystem (file group).
![Page 32: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/32.jpg)
35
Case Study: Andrew File System
Provides transparent access to remote shared file AFS compatible with NFS Differ markedly from NFS in its design &
implementation Design to perform well with larger numbers of
active users than other distributed file systems 2 unusual design characteristics:
~ Whole-file serving: The entire contents of directories and files are transmitted to client computers by AFS server
~ Whole-file caching: Once a copy of a file or its chunk has been transferred to a client computer, it is stored in a cache on the local disk.
![Page 33: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/33.jpg)
36
Andrew File System operation
client comp issues an open and no current copy in local cache, server holding is located and send request for a copy.
copy is stored in local UNIX in client comp subsequent read, write and other operation are
applied in local copy when client issues a close, updated will sent to the
server-timestamp and content. copy on the local disk is retained for other user in same workstation.
![Page 34: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/34.jpg)
37
AFS implementation How AFS control when an open or close system call
referring to a file in the shared file space is issued by client?
How the server holding the required file located? What space is allocated for cached files in
workstation How does AFS ensures that the cached copies are
up to date when many files updated by several clients?
![Page 35: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/35.jpg)
38
Fig. 8.11: Distribution of processes in the Andrew File
System
Venus
Workstations Servers
Venus
VenusUserprogram
Network
UNIX kernel
UNIX kernel
Vice
Userprogram
Userprogram
ViceUNIX kernel
UNIX kernel
UNIX kernel
Vice process: Server s/w to run the user processes at server.Venus process: Client s/w
![Page 36: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/36.jpg)
39
Fig. 8.12: File name space seen by clients of AFS in Unix
/ (root)
tmp bin cmuvmunix. . .
bin
SharedLocal
Symboliclinks
![Page 37: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/37.jpg)
40
Fig. 8.13: System call interception in AFS
UNIX filesystem calls
Non-local fileoperations
Workstation
Localdisk
Userprogram
UNIX kernel
Venus
UNIX file system
Venus
![Page 38: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/38.jpg)
41
Fig. 8.14: Implementation of file system calls in AFS
User process UNIX kernel Venus Net Viceopen(FileName,
mode)If FileName refers to afile in shared file space,pass the request toVenus.
Open the local file andreturn the filedescriptor to theapplication.
Check list of files inlocal cache. If notpresent or there is novalid callback promise,send a request for thefile to the Vice serverthat is custodian of thevolume containing thefile.
Place the copy of thefile in the local filesystem, enter its localname in the local cachelist and return the localname to UNIX.
Transfer a copy of thefile and a callbackpromise to theworkstation. Log thecallback promise.
read(FileDescriptor,Buffer, length)
Perform a normalUNIX read operationon the local copy.
write(FileDescriptor,Buffer, length)
Perform a normalUNIX write operationon the local copy.
close(FileDescriptor) Close the local copyand notify Venus thatthe file has been closed. If the local copy has
been changed, send acopy to the Vice serverthat is the custodian ofthe file.
Replace the filecontents and send acallback to all otherclients holdingcallbackpromises on the file.
![Page 39: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/39.jpg)
42
Cache consistency vice supply a file to venus also provide a callback
promise Callback promise stored with cached file on
workstation and have 2 state : valid and cancelled. when venus handles open on behalf of client, it
checks the cached. If it found in the cache, token is checked. If value is cancelled – fresh copy of file must be
fetch from Vice server. If valid – cached copy can be opened without
reference to Vice BUT, if worksation is restarted after a failure or
shutdown?
![Page 40: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/40.jpg)
43
Fig. 8.15: Main components of the Vice service interface
Fetch(fid) -> attr, data Returns the attributes (status) and, optionally, the contents of fileidentified by the fid and records a callback promise on it.
Store(fid, attr, data) Updates the attributes and (optionally) the contents of a specifiedfile.
Create() -> fid Creates a new file and records a callback promise on it.Remove(fid) Deletes the specified file.SetLock(fid, mode) Sets a lock on the specified file or directory. The mode of the
lock may be shared or exclusive. Locks that are not removed expire after 30 minutes.
ReleaseLock(fid) Unlocks the specified file or directory.RemoveCallback(fid) Informs server that a Venus process has flushed a file from its
cache.BreakCallback(fid) This call is made by a Vice server to a Venus process. It cancels
the callback promise on the relevant file.
![Page 41: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/41.jpg)
44
Enhancement and further
developments NFS Enhancement AFS Enhancement Improvement in storage organization
New design approaches
![Page 42: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/42.jpg)
45
Recent advances in file servicesNFS enhancements
WebNFS – The advent of Java and applets led to WebNFW. NFS server implements a web-like service on a well-known port. Requests use a 'public file handle' and a pathname-capable variant of lookup(). Enables applications to access NFS servers directly, e.g. to read a portion of a large file.
One-copy update semantics (Spritely NFS, NQNFS) - Include an open() operation and maintain tables of open files at servers, which are used to prevent multiple writers and to generate callbacks to clients notifying them of updates. Performance was improved by reduction in gettattr() traffic.
![Page 43: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/43.jpg)
46
Recent advances in file services (Cont.)
AFS enhancements: The design of DCE/DFS distributed file systems goes beyond AFS.
Improvements in disk storage organisationRAID - improves performance and reliability by striping
data redundantly across several disk drivesLog-structured file storage – – updated pages are stored contiguously in memory
and committed to disk in large contiguous blocks (~ 1 Mbyte).
– File maps are modified whenever an update occurs. – Garbage collection to recover disk space.
![Page 44: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/44.jpg)
47
New design ApproachesDistribute file data across several servers
– Exploits high-speed networks (ATM, Gigabit Ethernet)– Layered approach, lowest level is like a 'distributed
virtual disk'– Achieves scalability even for a single heavily-used file
'Serverless' architecture– Exploits processing and disk resources in all available
network nodes– Service is distributed at the level of individual files
![Page 45: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/45.jpg)
48
New design Approaches (Cont.)Examples:
xFS is serverless: Experimental implementation demonstrated a substantial performance gain over NFS and AFS
Frangipani is a hidhly scalable DS: Performance similar to local UNIX file access
Tiger Video File System Peer-to-peer systems: Napster, OceanStore (UCB),
Farsite (MSR), Publius (AT&T research)
![Page 46: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/46.jpg)
49
Replicated read-write files– High availability– Disconnected working
• re-integration after disconnection is a major problem if conflicting updates have ocurred
– Examples: • Bayou system• Coda system
New design Approaches (Cont.2)
![Page 47: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/47.jpg)
50
SummarySun NFS is an excellent example of a
distributed service designed to meet many important design requirements
Effective client caching can produce file service performance equal to or better than local file systems
Consistency versus update semantics versus fault tolerance remains an issue
Most client and server failures can be maskedSuperior scalability can be achieved with whole-file
serving (Andrew FS) or the distributed virtual disk approach
![Page 48: Chapter 5: Distributed File Systems](https://reader036.fdocuments.net/reader036/viewer/2022062501/568164eb550346895dd75750/html5/thumbnails/48.jpg)
Exercise
• Discuss the EIGHT (8) requirements of Distributed File System in detail.
• Discuss the cache consistency issue, if workstation is restarted after a failure or shutdown?
51