Distributed Information Systems Lecture 10 - Distributed File Systems, Lecture notes of Computers and Information technologies

Download Distributed Information Systems Lecture 10 - Distributed File Systems and more Lecture notes Computers and Information technologies in PDF only on Docsity!

Distributed File

Systems

Dr Simon Blake

Topics for this lecture

• File Service architecture• Sun’s Network File System (NFS)• An introduction to Andrew File System

(AFS)

File Service Architecture

• A directory

• a special type of file– provides the mapping from text names to

internal file identifier

• directories may appear within directories– Form hierarchical file storage structures

J: J:\StaffJ:\Staff\DutiesJ:\Staff\Budget

J:
J:\STAFF

J:\STAFF\BUDGET

J:\STAFF\DUTIES

File Service Architecture

• File management systems typically have a

layered module structure

Directory module:

Relates user-attributed filenames to file IDs

File module:

Relates file IDs to particular (physically stored) 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 device driver

):^

Disk I/O and buffering

DFS requirements

-^

What are the requirements of a distributed fileservice?

-^

DFS extends and includes:^ – access to data file– access to application executable files– access to some system configuration information

stored in files (in some systems)

• offers persistent location-transparent Inter-Process

Communication (IPC) via shared files

DFS requirements

•^

Also it should provide transparency:^ – Access transparency– Location transparency– Concurrency transparency– Failure transparency– Performance transparency

-^

Other require features:^ – Support for hardware and operating system heterogeneity– Scalability– Replication transparency– Migration transparency

DFS requirements

•^

File sharing semantics –^

UNIX Semantics •^

Every operation on a file is instantly visible to allprocesses

-^

Easy to implement if there is only one copy ofeach file held by the file service and no clientcaches

DFS requirements

•^

File sharing semantics –^

Session Semantics •^

a barrier to concurrency

-^

Files are ‘locked’ for the duration of the accesssession (delimited by an Open and a Close)

-^

Only the client that has opened the file can seeintermediate states of the file

-^

Other clients only see the effects of changes afterthe file has been closed

-^

Good if concurrent access to files is rare

DFS requirements

•^

File sharing semantics –^

Transactions •^

All changes have the all-or-nothing property

-^

Necessary for consistency where replicawriteable copies exist

-^

Good way of achieving concurrency transparency

DFS Replication & Consistency •

DFS can support replication –^

A replica is a copy of a portion or all of some data

-^

The main benefit being - locality of reference

-^

The main problem being - consistency

•^

Generally

read access

write access

•^

Good compromise is to make all but one replica read-only

-^

After a write update, the changes are propagated to theread-only copies

-^

Clients can be sent ‘invalidation’ messages signallingthe need for an update

DFS: An Architecture

DFS components

• File service

• This service is concerned with implementing

operations on the contents of files

• Use Unique File Identifiers (UFIDs)– UFIDs are used in all requests to the file

system

DFS components

• Client Module

• One per client computer– integrates the operations of the file service

and the directory service under a singleapplication programming interface

• Provides location transparency to the

application programs

• The client module may implement a caching

system

Sun NFS

•^

Uses flat file with directory service and client module

-^

NFS protocol^ – RPC based, OS independent (originally UNIX)– NFS server– stateless (no open/close)– no locks or concurrency control– no replication with updates

-^

Virtual file system, remote mount

-^

Access control (user id with each request)^ – security loophole (modify RPC to impersonate user…)

-^

Client and server caching