17-filesystems

8/3/2019 17-filesystems

1/38

Distributed File Systems


2/38

2

Distributed File System Architecture

a) The remote access modelb) The upload/download model (used e.g. in FTP)


3/38

3

Two Examples

NFS (Sun Network File System)Developed by Sun for use on its UNIX-basedworkstations

Implemented for many other systems

More a model(collection of protocols)thanimplementation

Currently used NFS version 3NFS version 4 is almost ready

CodaSupport forcontinuous operations (e.g. laptop connected/

disconnected)


4/38

NFS


5/38

5

NFS Architecture

The basic NFS architecture for UNIX systems.


6/38

6

Communication

Independent of operating system, networkarchitecture, and transport protocol

Based on RPC Client ideology: make servers life as simple as

possibleOne RPC call perfile operation

NFS version 4 supports compound procedures


7/38

7

Processes

Traditional client-server architecture

Server can bestateless Abandoned in NFS version 4

Simplicity (no error recovering, etc)Separate (stateful) lock manager


8/38

8

Naming (1)

Directories are exportedand mounted Names are relevant to the client

Standardized names


9/38

9

Naming (2)

It is not allowed to re-export directories Client has to explicitly mount from the

corresponding server


10/38

10

Synchronization Problemsa) On a single processor, when a

readfollows a write, the value

returned by the readis the value

just written.

b) In a distributed system withcaching, obsolete values may be

returned.


11/38

11

File Locking in NFS

NFS version 4 operations related to file locking.

Operation Description

Lock Creates a lock for a range of bytes

Lockt Test whether a conflicting lock has been granted

Locku Remove a lock from a range of bytesRenew Renew the leas on a specified lock


12/38

12

Client Caching in NFS

NFS implements session semantics (the cached datais flushed back to the server when the client closes

the file)


13/38


14/38

14

Security

The NFS security architecture.


15/38

15

Secure RPCs

Secure RPC in NFS version 4.


16/38

16

Access Control (1)

The classification of operations recognized by NFS with respect to access control.


Read_data Permission to read the data contained in a file

Write_data Permission to to modify a file's data

Append_data Permission to to append data to a file

Execute Permission to to execute a file

List_directory Permission to to list the contents of a directory

Add_file Permission to to add a new file t5o a directory

Add_subdirectory Permission to to create a subdirectory to a directory

Delete Permission to to delete a file

Delete_child Permission to to delete a file or directory within a directory

Read_acl Permission to to read the ACL

Write_acl Permission to to write the ACL

Read_attributes The ability to read the other basic attributes of a file

Write_attributes Permission to to change the other basic attributes of a file

Read_named_attrs Permission to to read the named attributes of a file

Write_named_attrs Permission to to write the named attributes of a fileWrite_owner Permission to to change the owner

Synchronize Permission to to access a file locally at the server with synchronous reads and writes


17/38

17

Access Control (2)

The various kinds of users and processes distinguished by

NFS with respect to access control.

Type of user Description

Owner The owner of a file

Group The group of users associated with a file

Everyone Any user of a process

Interactive Any process accessing the file from an interactive terminal

Network Any process accessing the file via the network

Dialup Any process accessing the file through a dialup connectionto the server

Batch Any process accessing the file as part of a batch job

Anonymous Anyone accessing the file without authentication

Authenticated Any authenticated user of a process

Service Any system-defined service process


18/38

Coda


19/38

19

Distributed File System Architecture

a) The remote access modelb) The upload/download model (used e.g. in FTP)


20/38

20

Coda

Developed in Carnegie Melon University (CMU) in1990s

Designed to support around 10,000 workstations Aimed at high availability Available in a number of operating system (Linux) Vice file servers Virtue workstations

Every workstation runs a process called Venus (similarto an NFS client)


21/38

21

Overview of Coda (1)

The overall organization of Coda


22/38

22

Overview of Coda (2)

The internal organization of a Virtue workstation.


23/38

23

Communication

By means of RPC Reliable and more sophisticated RPC2Supports multicastingSupports multiple RPCs in parallelSupports other features (e.g., side effects: communication

using an application-specific protocol on top of RPC)


24/38

24

Processes

Clearly distinguishes clients and servers Both are organized as a collection of concurrent

threads

User-space implementation + special mechanismsdealing with blocking I/O operations


25/38

25

Naming (1)

Analogous to UNIX

Files are grouped into volumesUsually corresponds to a collection of files associated

with a user

Each file is contained in exactly on volume

Shared files have identical names at all clientsUnder UNIX, always mounted under the/afs directory


26/38

26

Naming (2)

Clients in Coda have access to a single shared name space.


27/38

27

How it Works

When a client opens a file, an entire copy of the fileis transferred to the clients machine.

Several clients may open the same file for reading Transactional semantics is used to prevent write-

write conflicts:When a client opens a file for writing, nobody else is

allowed to open it for writing

When a client closes the file, the file will be transferredback to the server


28/38

28

Synchronization Problem

How would transactional semantics work if a server

is not reachable?

All operations succeed on the clients side Version controlis used When the server is again available, updates are

transferred to the server in the same order as they

took place at the client

When a conflict occurs, the updates from theclients session are undone

Manual reconciliation


29/38

29

Client Caching (1)

Achieves scalability Higher degree of fault tolerance (clients are less

dependent on the server availability)

Caches may become invalid Callback promise: the server notifies the client

data invalidation

The server keeps track of all clients

The client can safely use the local copy until aninvalidation notification comes


30/38

30

Server Replication (1)

Coda allows volumes to be replicatedVolume storage group (VSG) a group of servers

keeping the same volume

A client contacts one of the active VSG in order toget a file

When closing a session on an updated file, theclient transfers it in parallel to allmembers of

ASVG

Conflicts may occur when the network ispartitioned


31/38

31


Two clients with different AVSG for the same replicatedfile

Each server maintains versions of the files


32/38

32


When the network partitioning is healed serversreintegrate their copies of the files

Comparison of versions In many cases conflict resolution may be automated in an

application-dependent way In some cases users have to assist (especially, when

several users changed the same part of the same file in

different ways)

In practice, conflicts are rare


33/38

33

Fault Tolerance

In NFS (and many other distributed file systems) aclient cannot operate unless it can contact a server

In Coda it can use the local copy and then rely onconflict recovery

Provided that all needed files are in the cacheCoda uses a sophisticated priority mechanism to ensure

that useful data is cached

Hoarding: filling the cache


34/38

34

Disconnected Operation

The state-transition diagram of a Coda client with respect to a volume.


35/38

35

Security

Secure channel for authentication & privacySame ideas as in Kerberos, different implementation

Access controlFor simplicity and scalability, access control lists for

directories (not individual files) only

Ability to give negative rights to punish misbehavingusers faster


36/38

36

Access Control

Classification of file and directory operations

recognized by Coda with respect to access control.


Read Read any file in the directory

Write Modify any file in the directory

Lookup Look up the status of any file

Insert Add a new file to the directory

Delete Delete an existing file

Administer Modify the ACL of the directory


37/38

37

Summary (1)

Issue NFS Coda

Design goalsAccess

transparencyHigh availability

Access model Remote Up/Download

Communication RPC RPCClient process Thin/Fat Fat

Server groups No Yes

Mount granularity Directory File system

File ID scope File server GlobalName space Per client Global


38/38

38

Summary (2)

Sharing sem. Session TransactionalCache consist. write-back write-back

Replication Minimal ROWA

Fault tolerance Reliable comm. Replication and

caching

Recovery Client-based Reintegration

Secure channels Existing

mechanisms

Needham-

Schroeder

Access control Many operations Directory

operations

17-filesystems

Documents