05/31/2006 ecs150, spring 2006 1 UCDavis, ecs150 Spring 2006 ecs150 Spring 2006: Operating System Operating System #7: mbuf (Chapter 11) Dr. S. Felix Wu Computer Science Department University of California, Davis http://www.cs.ucdavis.edu/~wu/ [email protected]
71
Embed
UCDavis, ecs150 Spring 2006 05/31/2006ecs150, spring 20061 Operating System ecs150 Spring 2006 : Operating System #7: mbuf (Chapter 11) Dr. S. Felix Wu.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
05/31/2006 ecs150, spring 2006 1
UCDavis, ecs150Spring 2006
ecs150 Spring 2006:Operating SystemOperating System#7: mbuf(Chapter 11)
Dr. S. Felix Wu
Computer Science Department
University of California, Davishttp://www.cs.ucdavis.edu/~wu/
UCDavis, ecs150Spring 2006 State-ful vs. State-lessState-ful vs. State-less
A server is fully aware of its clients– does the client have the newest copy?
– what is the offset of an opened file?
– “a session” between a client and a server!
A server is completely unaware of its clients– memory-less: I do not remember you!!
– Just tell me what you want to get (and where).
– I am not responsible for your offset values (the client needs to maintain the state).
05/31/2006 ecs150, spring 2006 55
UCDavis, ecs150Spring 2006 The StateThe State
applications
openreadstatlseek
applications
openreadstatlseek
offset
05/31/2006 ecs150, spring 2006 56
UCDavis, ecs150Spring 2006
Unix file semanticsUnix file semantics
NFS:– open a file with read-write mode– later, the server’s copy becomes read-only
mode– now, the application tries to write it!!
05/31/2006 ecs150, spring 2006 57
UCDavis, ecs150Spring 2006
Problems with NFSProblems with NFS
Performance not scaleable:– maybe it is OK for a local office.– will be horrible with large scale systems.
05/31/2006 ecs150, spring 2006 58
UCDavis, ecs150Spring 2006
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 optimisations.
– 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:– 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.
*
05/31/2006 ecs150, spring 2006 59
UCDavis, ecs150Spring 2006 Server caching does nothing to reduce RPC traffic between client and
server– further optimisation 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. 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
05/31/2006 ecs150, spring 2006 60
UCDavis, ecs150Spring 2006 AFSAFS
State-ful clients and servers. Caching the files to clients.
– File close ==> check-in the changes. How to maintain consistency?
– Using “Callback” in v2/3 (Valid or Cancelled)
openread
applications
invalidate and re-cache
05/31/2006 ecs150, spring 2006 61
UCDavis, ecs150Spring 2006 Why AFS?Why AFS?
Shared files are infrequently updated Local cache of a few hundred mega bytes
– Now 50~100 giga bytes Unix workload:
– Files are small, Read Operations dominated, sequential access is common, read/written by one user, reference bursts.
– Are these still true?
05/31/2006 ecs150, spring 2006 64
UCDavis, ecs150Spring 2006 Fault Tolerance in AFSFault Tolerance in AFS
a server crashes
a client crashes– check for call-back tokens first.
05/31/2006 ecs150, spring 2006 65
UCDavis, ecs150Spring 2006
Problems with AFSProblems with AFS
Availability what happens if call-back itself is lost??
05/31/2006 ecs150, spring 2006 66
UCDavis, ecs150Spring 2006
GFS – Google File SystemGFS – Google File System
“failures” are norm Multiple-GB files are common Append rather than overwrite
– Random writes are rare Can we relax the consistency?
05/31/2006 ecs150, spring 2006 67
UCDavis, ecs150Spring 2006
05/31/2006 ecs150, spring 2006 68
UCDavis, ecs150Spring 2006
05/31/2006 ecs150, spring 2006 69
UCDavis, ecs150Spring 2006
CODACODA
Server Replication:– if one server goes down, I can get another.
Disconnected Operation:– if all go down, I will use my own cache.
05/31/2006 ecs150, spring 2006 70
UCDavis, ecs150Spring 2006
ConsistencyConsistency
If John update file X on server A and Mary read file X on server B….
Read-one & Write-all
05/31/2006 ecs150, spring 2006 71
UCDavis, ecs150Spring 2006 Read x & Write (N-x+1)Read x & Write (N-x+1)