tính toán song song thoại nam distributedsystem 16 fileservice sinhvienzone com

Teaching material
based on Distributed
Systems: Concepts
and Design, Edition 3,
Addison-Wesley 2001.

Distributed Systems Course

Viewing: These slides
must be viewed in
slide show mode.

nh
Vi
en

Zo

Chapter 2 Revision: Failure model
Chapter 8:
8.1
8.2
8.3
[8.4
8.5
8.6

Si

Copyright © George
Coulouris, Jean Dollimore,

Tim Kindberg 2001
email:
This material is made
available for private study
and for direct use by
individual teachers.
It may not be included in any
product or employed in any
service without the written
permission of the authors.

ne

.C

om

Distributed File Systems

SinhVienZone.com

Introduction
File service architecture
Sun Network File System (NFS)
Andrew File System (personal study)]
Recent advances
Summary
/>

om

Learning objectives

ne

.C

 Understand the requirements that affect the design
of distributed services

nh
Vi
en

Obtain a knowledge of file systems, both local and networked
Caching as an essential design technique
Remote interfaces are not the same as APIs
Security requires special consideration

Si

–
–
–
–

Zo

 NFS: understand how a relatively simple, widelyused service is designed

 Recent advances: appreciate the ongoing research
that often leads to major advances
SinhVienZone.com

2

/>

Chapter 2 Revision: Failure model

Description
Process halts and remains halted. Other processes may
detect this state.
Crash
Process Process halts and remains halted. Other processes may
not be able to detect this state.
Omission
Channel A message inserted in an outgoing message buffer never
arrives at the other end’s incoming message buffer.
Send-omission Process A process completes a send, but the message is not put
in its outgoing message buffer.
Receive-omission Process A message is put in a process’s incoming message
buffer, but that process does not receive it.
Arbitrary
Process Process/channel exhibits arbitrary behaviour: it may
(Byzantine)
or channel send/transmit arbitrary messages at arbitrary times,
commit omissions; a process may stop or take an
incorrect step.

.C

Affects
Process

Si

nh
Vi
en

Zo

ne

Class of failure
Fail-stop

om

Figure 2.11

SinhVienZone.com

3

/>

om

Storage systems and their properties

ne

.C

 In first generation of distributed systems (1974-95),
file systems (e.g. NFS) were the only networked
storage systems.

Si

nh
Vi
en

Zo

 With the advent of distributed object systems
(CORBA, Java) and the web, the picture has
become more complex.

SinhVienZone.com

4

/>

Storage systems and their properties

om

Types of consistency between copies: 1 - strict one-copy consistency
√ - approximate consistency
X - no automatic consistency

.C

Figure 8.1

ne

Sharing Persis- Distributed
Consistency Example
tence
cache/replicas maintenance

File system
Distributed file system
Web

1

RAM

1

UNIX file system
Sun NFS
Web server

Ivy (Ch. 16)

Si

Distributed shared memory

nh
Vi
en

Zo

Main memory

Remote objects (RMI/ORB)

1

CORBA

Persistent object store

1

CORBA Persistent
Object Service

Persistent distributed object store
SinhVienZone.com

PerDiS, Khazana
5

/>

What is a file system?

1

om

 Persistent stored data sets

.C

 Hierarchic name space visible to all processes

ne

 API with the following characteristics:

Zo

– access and update operations on persistently stored data sets
– Sequential access model (with additional random facilities)

nh
Vi
en

 Sharing of data between users, with access control

 Concurrent access:

– certainly for read-only access
– what about updates?

Si

 Other features:

– mountable file stores
– more? ...

SinhVienZone.com

6

/>
*


2

om

What is a file system?

ne

nh
Vi
en

status = close(filedes)
count = read(filedes, buffer, n)
count = write(filedes, buffer, n)

Opens an existing file with the given name.
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.
Closes the open file filedes.
Transfers n bytes from the file referenced by filedes to buffer.
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.
Moves the read-write pointer to offset (relative or absolute,
depending on whence).
Removes the file name from the directory structure. If the file
has no other names, it is deleted.
Adds a new name (name2) for a file (name1).
Gets the file attributes for file name into buffer.

Zo

filedes = open(name, mode)
filedes = creat(name, mode)

.C

Figure 8.4 UNIX file system operations

Si

pos = lseek(filedes, offset,
whence)
status = unlink(name)
status = link(name1, name2)
status = stat(name, buffer)
SinhVienZone.com

7

/>
*


4

om

What is a file system?
Figure 8.3 File attribute record structure

ne

.C

File length

Creation timestamp

updated
by system:

nh
Vi
en

Zo

Read timestamp
Write timestamp

updated
by owner:

Si

Attribute timestamp
Reference count
Owner
File type
Access control list

E.g. for UNIX: rw-rw-r-SinhVienZone.com

9

/>

*


File service requirements

 Heterogeneity
 Fault tolerance
 Consistency

 Efficiency..

om

.C

Si

 Security

ne

 Replication

Zo

 Concurrency

Tranparencies
Concurrency
properties

Replication
properties
Heterogeneity
Access:
Sameproperties
operations
Fault
tolerance
Consistency
Isolation
Security
File
service
maintains
multiple
identical
copies
of
Efficiency
Service
can
be
accessed
by
clients
running
on
Location:
Same
name

space
after
relocation
of
Service
must
continue
tocontrol
operate
even
when
Unix
offers
one-copy
update
semantics
for asclients
File-level
or
record-level
locking
files
Must
maintain
access
and
privacy
(almost)
any
OS

or hardware
platform.
Goal
for
distributed
file systems
is usually for
files
or
processes
make
errors
or
crash.
operations
on local files - caching is completely
local
files.
Other
forms
of
concurrency
control
to
minimise
•
Load-sharing
between
servers
makes

service
performance
comparable
tothe
local
file
system.
Design
must
be
compatible
with
file
systems
of
Mobility:
Automatic
relocation
of
files
is
possible
transparent.
•more
at-most-once
semantics
•based
on identity of user making request
contention
scalable

different
OSes
Performance:
Satisfactory
performance
across a
Difficult
to
achieve
the
same
for
distributed
file
•
at-least-once
semantics
•identities
of
remote
users must
be authenticated
• Service
Local access
has
better
response
(lower
latency)
specified

rangebe
of open
system
loads
interfaces
must
- precise
systems
while
maintaining
good
performance
•requires
idempotent
operations
•privacy
requires
secure
communication
• Fault
specifications
APIs
published.
Scaling:
Service of
can
be are
expanded
to meet
andtolerance

scalability.
Service must
resume
after
a server
machine not
interfaces
are
open
to all processes
additional
loads
FullService
replication
is difficult
to
implement.
crashes.
excluded by a firewall.
Caching (of all or part of a file) gives most of the
If the service
is replicated,
it can continue
impersonation
andto
other
benefits •vulnerable
(except faulttotolerance)
operate
even during a server crash.

attacks

nh
Vi
en

 Transparency

SinhVienZone.com

10

/>
*


Model file service architecture
Figure 8.5

om

Lookup
AddName
UnName
GetNames

ne

Server computer
Directory service

Zo

nh
Vi
en

Application Application
program
program

.C

Client computer

Flat file service

Si

Client module

SinhVienZone.com

Read
Write
Create
Delete
GetAttributes
SetAttributes
11

/>

Server operations for the model file service

om

Figures 8.6 and 8.7
Flat file service

Directory service

.C

position of first byte

Delete(FileId)

nh
Vi
en

Create() -> FileId

Si

GetAttributes(FileId) -> Attr

SetAttributes(FileId, Attr)

SinhVienZone.com

Zo

position of first byte

Write(FileId, i, Data)

Lookup(Dir, Name) -> FileId
FileId
AddName(Dir, Name, File)

ne

Read(FileId, i, n) -> Data

UnName(Dir, Name)
GetNames(Dir, Pattern) -> NameSeq
Pathname lookup
FileId
Pathnames
such as '/usr/bin/tar' are resolved
Aby
unique
identifier
anywhere
thefor
iterative
callsfor
to files

lookup(),
oneincall
network.
each component of the path, starting with
the ID of the root directory '/' which is
known in every client.
12

/>
*


om

File Group

Zo

ne

located on any server or moved
between servers while
maintaining the same names.

Si

nh
Vi
en

– 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

SinhVienZone.com

13

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.

.C

A collection of files that can be

File Group ID:
32 bits
IP address

/>
16 bits

date

*


om

Case Study: Sun NFS
 An industry standard for file sharing on local networks since the 1980s

.C

 An open standard with clear and simple interfaces

ne

 Closely follows the abstract file service model defined above
transparency
heterogeneity
efficiency
fault tolerance

nh
Vi
en

–
–
–
–

Zo

 Supports many of the design requirements already mentioned:

–
–
–
–

concurrency
replication
consistency
security

Si

 Limited achievement of:

SinhVienZone.com

14

/>
*


NFS architecture
Client computer

om

Figure 8.8

NFS
Application
program Client

Application Application
program
program

Operations
on local files

ne
Operations
on
remote files

NFS
client

Virtual file system

NFS
server

NFS
Client

Si

UNIX
file
system

nh
Vi
en

Virtual file system
Other
file system

UNIX kernel

Application
program

Kernel

Zo

UNIX
system calls

Server computer

.C

Client computer

UNIX
file
system

NFS
protocol
(remote operations)
SinhVienZone.com

15

/>
*


om

NFS architecture:
does the implementation have to be in the system kernel?
No:

Zo

ne

.C

– there are examples of NFS clients and servers that run at applicationlevel as libraries or processes (e.g. early Windows and MacOS
implementations, current PocketPC, etc.)

nh
Vi
en

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

Si

– 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.
SinhVienZone.com

16

/>
*


NFS server operations (simplified)

nh

Vi
en

Zo

ne

.C

fh = fileModel
handle:flat file service
read(fh, offset, count) -> attr, data
Read(FileId, i, n) -> Data
write(fh, offset, count, data) -> attr
identifier i-node
number i-node generation
Write(FileId,
i, Data)
create(dirfh, name, attr) -> newfh, attr Filesystem
Create() -> FileId
remove(dirfh, name) status
Delete(FileId)
getattr(fh) -> attr
GetAttributes(FileId) -> Attr
setattr(fh, attr) -> attr
SetAttributes(FileId, Attr)
lookup(dirfh, name) -> fh, attr
rename(dirfh, name, todirfh, toname)
Model directory service
link(newdirfh, newname, dirfh, name)

Lookup(Dir, Name) -> FileId
readdir(dirfh, cookie, count) -> entries
AddName(Dir, Name, File)
symlink(newdirfh, newname, string) -> statusUnName(Dir, Name)
readlink(fh) -> string
GetNames(Dir, Pattern)
mkdir(dirfh, name, attr) -> newfh, attr
->NameSeq
rmdir(dirfh, name) -> status
statfs(fh) -> fsstats

Si

•
•
•
•
•
•
•
•
•
•
•
•
•
•
•

om

Figure 8.9

SinhVienZone.com

17

/>
*


om

NFS access control and authentication

.C

 Stateless server, so the user's identity and access rights must
be checked by the server on each request.

ne

– In the local file system they are checked only on open()

Zo

 Every client request is accompanied by the userID and groupID

nh
Vi

en

– not shown in the Figure 8.9 because they are inserted by the RPC system

 Server is exposed to imposter attacks unless the userID and
groupID are protected by encryption

Si

 Kerberos has been integrated with NFS to provide a stronger
and more comprehensive security solution
– Kerberos is described in Chapter 7. Integration of NFS with Kerberos is covered
later in this chapter.

SinhVienZone.com

18

/>
*


om

Mount service

ne

.C

 Mount operation:
mount(remotehost, remotedirectory, localdirectory)

nh
Vi
en

Zo

 Server maintains a table of clients who have
mounted filesystems at that server

Si

 Each client maintains a table of mounted file
systems holding:
< IP address, port number, file handle>
 Hard versus soft mounts

SinhVienZone.com

19

/>
*


Local and remote file systems accessible on an NFS client

Client

(root)

(root)

...

usr

nfs

Remote

people

mount

students

Remote
x

Si

big jon bob

vmunix

nh
Vi
en

export

Zo

ne

(root)

Server 2

.C

Server 1

om

Figure 8.10

...

staff

mount

users

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.

SinhVienZone.com

20

/>
*


om

NFS optimization - server caching
 Similar to UNIX file caching for local files:

nh
Vi
en

Zo

ne

.C

– 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.

 NFS v3 servers offers two strategies for updating the disk:

Si

– 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.
– 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.

SinhVienZone.com

23

/>
*


om

NFS optimization - client caching

.C

 Server caching does nothing to reduce RPC traffic between
client and server

ne

– further optimization is essential to reduce server load in large networks

nh
Vi
en

Zo

– 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.

 Timestamp-based validity check

Si

– 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
SinhVienZone.com

24

t
Tc

freshness guarantee
time when cache entry was last
validated
Tm time when block was last
updated at server
T current time
/>
*


om

Other NFS optimizations
 Sun RPC runs over UDP by default (can use TCP if required)

ne

.C

 Uses UNIX BSD Fast File System with 8-kbyte blocks

Zo

 reads() and writes() can be of any size (negotiated between
client and server)

nh

Vi
en

 the guaranteed freshness interval t is set adaptively for
individual files to reduce gettattr() calls needed to update Tm

Si

 file attribute information (including Tm) is piggybacked in
replies to all file requests

SinhVienZone.com

25

/>
*


NFS summary

1

.C

om

 An excellent example of a simple, robust, high-performance
distributed service.

ne

 Achievement of transparencies (See section 1.4.7):

Zo

Access: Excellent; the API is the UNIX system call interface for both local
and remote files.

nh
Vi
en

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.

Si

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, the SUN
Network Information Service (NIS) runs over NFS and is used to
replicate essential system files, see Chapter 14.
SinhVienZone.com

27

/>

cont'd *


NFS summary

2

om

Achievement of transparencies (continued):

ne

.C

Failure: Limited but effective; service is suspended if a server fails.
Recovery from failures is aided by the simple stateless design.
Mobility: Hardly achieved; relocation of files is not possible, relocation of

Zo

filesystems is possible, but requires updates to client configurations.

nh
Vi
en

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.

Si

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).

SinhVienZone.com

28

/>
*


om

Recent advances in file services
NFS enhancements

nh
Vi
en

Zo

ne

.C

WebNFS - 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.

Improvements in disk storage organisation

Si

RAID - improves performance and reliability by striping data redundantly across
several disk drives
Log-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.
SinhVienZone.com

34

/>
*