CHAPTER 6: DISTRIBUTED FILE SYSTEMS

Chapter outline
DFS design and implementation issues: system structure, le access, and sharing semantics Transaction and concurrency control: serializability and concurrency control protocols Replicated data management: one-copy serializability and coherency control protocols

Why is DFS important and interesting?

It is one of the two important components (process and le) in any distributed computation. It is a good example for illustrating the concept of transparency and client/server model. File sharing and data replication present many interesting research problems.

Structure of and access to a le system

directory service authorization service file service transaction basic

name resolution, add and deletion of files capability and / or access control list concurrency and replication management read / write files and get / set attributes device, cache, and block management

system service

File: sequential, direct, indexed-sequential File System: at, hierarchical

root chow book paper process lecture file paper PRlock johnson report Btree

Mounting protocols and NFS

Explicit mounting Boot mounting Auto mounting

root chow paper book mount local client export DFS OS

root

DSM

security

remote server

Stateful and stateless le servers Opened les and their clients File descriptors and le handles Current le position pointers Mounting information Lock status Session keys Cache or buer

Semantics of sharing in DFS

space time simple RW transaction session

remote access no true sharing concurrency control not applicable

cache access coherency control coherency and concurrency not applicable

down/up load access coherency control coherency and concurrency ignore sharing

sharing Unix semantics - currentness Transaction semantics - consistency Session semantics - eciency

replication Write policies: write-through and write back cache coherence control: write-invalidate and write-update Version control (immutable les): ignore conict, resolve version conict, resolve serializability conict

Transaction and concurrency control

Coordinator clients transaction manager scheduler object manager objects

Communication Participants clients transaction manager TM scheduler SCH object manager OM objects

transaction processing system (TPS) Transaction manager (TM) Scheduler (SCH) Object manager (OM)

atomicity All or none: TM, two-phase commit Indivisible (serializable): SCH, concurrency control protocols Atomic update: OM, replica management

Serializability
IF the interleaved execution of transactions is to be equivalent to a serial execution in some order, then all conicting operations in the interleaved serializable schedule must also be executed in the same order at all object sites.

t0 : bt Write A=100, Write B=20 et t1 : bt Read A, Read B, 1: Write sum in C, 2: Write di in D et t2 : bt Read A, Read B, 3: Write di in C, 4: Write sum in D et

Sched Interleave Log in C 1 1, 2, 3, 4 W1 = 120 W2 = 80 2 3, 4, 1, 2 W2 = 80 W1 = 120 3 1, 3, 2, 4 W1 = 120 W2 = 80 4 3, 1, 4, 2 W2 = 80 W1 = 120 5 1, 3, 4, 2 W1 = 120 W2 = 80 6 3, 1, 2, 4 W2 = 80 W1 = 120

Log in D Result (C,D) W1 = 80 (80, 120) W2 = 120 consistent W2 = 120 (120, 80) W1 = 80 consistent W1 = 80 (80, 120) W2 = 120 consistent W2 = 120 (120, 80) W1 = 80 consistent W2 = 120 (80, 80) W1 = 80 inconsistent W1 = 80 (120, 120) W2 = 120 inconsistent

2PL feasible feasible not feasible not feasible not feasible not feasible

Timestamp feasible t1 aborts and restarts feasible t1 aborts and restarts cascade aborts t1 aborts and restarts

Concurrency control protocols

Two-phase locking locking and shrinking phases of requesting and releasing objeccts concurrency versus serializability rolling abort, strict two-phase locking

Timestamp ordering

Read

abort RD WR abort

OK

wait waiting reads T min tentative writes

Write

do tentative write

RD Abort WR RD Commit WR

remove transaction from waiting list

T min cannot commit a waiting read

T min abort transactions

Optimistic concurrency control Execution phase Validation phase: 1. Validation of transaction ti is rejected if T Vi < T Vk . All transactions must be serialized with respect to T V . 2. Validation of transaction ti is accepted if it does not overlap with any tk . ti is already serialized with respect to tk . 3. The execution phase of ti overlaps with the update phase of tk , and tk completes its update phase before T Vi . Validation of ti is accepted if Ri Wk = . 4. The execution phase of ti overlaps with the validation and update phases of tk , and tk completes its execution phase before T Si . Validation of ti is accepted if Ri Wk = and Wi Wk = . Update phase

accept if no r-w & w-w reject execution phase TV i conflict TV i

accept if no r-w conflict TV i TS i accept TV i

TVk

validation phase

update phase

Data and le replication

Architecture of a replica manager

clients

FSA

RM

RM

clients

FSA

RM

RM

FSA : File Service Agent

RM : Replica Manager

read operations Read-one-primary Read-one Read-quorum

write operation Write-one-primary Write-all Write-all-available Write-quorum Write-gossip

One-copy serializability
The execution of transactions on replicated objects is equivalent to the execution of the same transactions on nonreplicated objects. Some approaches: read-one-primary/write-one-primary read-one/write-all read-one/write-all-available

failures Failures can cause problems with one-copy serializability. For example:

t0 : bt W (X) W (Y ) et t1 : bt R(X) W (Y ) et t2 : bt R(Y ) W (X) et t1 : bt R(Xa ) (Yd fails) W (Yc ) et t2 : bt R(Yd ) (Xa fails) W (Xb ) et

10

Quorum voting
From read-one/write-all-availble to read-quorum/write quorum:

1. Write-write conict: 2 W (d) > V (d). 2. Read-write conict : R(d) + W (d) > V (d).

6 7

6 8 7 8

8 8 8

: RMs : Witnesses 6, 7, 8 are version numbers.

R( d)=5

W( d ) = 5

11

Gossip update propagation

Lazy update propagation: read-one/write-gossip

Basic gossip protocol: read/overwrite Causal order gossip protocol: read/modify-update

TSf < TSi Client FSA Read update RM

TSi < TSj RM Gossip Gossip value V R update log L value V R update log L RM

value Read - modify V updates R update log L

RM 1 u 1 , 000 u 2 , 100 Gossip

RM 2 u 3 , 100

RM 3

Gossip

V = 100 R = 100 update log L : r 1 = 100 , u 1 = 000

V = 000 R = 110 update log L : r2 = 110 , u 2 = 100 r1 = 100 , u 1 = 000

V = 000 R = 111 update log L : r3 = 101 , u 3 = 100 r2 = 110 , u 2 = 100 r1 = 100 , u 1 = 000

12