DOC PREVIEW
Berkeley COMPSCI 162 - Lecture 25 Distributed File Systems

This preview shows page 1-2-24-25 out of 25 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 25 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 25 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 25 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 25 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 25 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

CS162 Operating Systems and Systems Programming Lecture 25 Distributed File SystemsReview: RPC Information FlowGoals for TodayRPC Details (continued)Problems with RPCCross-Domain Communication/Location TransparencyMicrokernel operating systemsDistributed File SystemsVirtual File System (VFS)Simple Distributed File SystemAdministriviaUse of caching to reduce network loadFailuresSchematic View of NFS ArchitectureNetwork File System (NFS)NFS ContinuedNFS Cache consistencySequential Ordering ConstraintsNFS Pros and ConsAndrew File SystemAndrew File System (con’t)World Wide WebWWW CachingWWW Proxy CachesConclusionCS162Operating Systems andSystems ProgrammingLecture 25Distributed File SystemsNovember 26, 2008Prof. John Kubiatowiczhttp://inst.eecs.berkeley.edu/~cs162Lec 25.211/26/08 Kubiatowicz CS162 ©UCB Fall 2008Review: RPC Information FlowClient(caller)Server(callee)PacketHandlerPacketHandlercallreturnsendreceivesendreceivereturncallNetworkNetworkClientStubbundleargsbundleret valsunbundleret valsServerStubunbundleargsMachine AMachine Bmbox1mbox2Lec 25.311/26/08 Kubiatowicz CS162 ©UCB Fall 2008Goals for Today•Finish Remote Procedure Call•Examples of Distributed File Systems–Cache Coherence Protocols for file systemsNote: Some slides and/or pictures in the following areadapted from slides ©2005 Silberschatz, Galvin, and Gagne. Slides on Testing from George Necula (CS169)Many slides generated from my lecture notes by Kubiatowicz.Lec 25.411/26/08 Kubiatowicz CS162 ©UCB Fall 2008RPC Details (continued)•How does client know which mbox to send to?–Need to translate name of remote service into network endpoint (Remote machine, port, possibly other info)–Binding: the process of converting a user-visible name into a network endpoint»This is another word for “naming” at network level»Static: fixed at compile time»Dynamic: performed at runtime•Dynamic Binding–Most RPC systems use dynamic binding via name service»Name service provides dynamic translation of servicembox–Why dynamic binding?»Access control: check who is permitted to access service»Fail-over: If server fails, use a different one•What if there are multiple servers?–Could give flexibility at binding time»Choose unloaded server for each new client–Could provide same mbox (router level redirect)»Choose unloaded server for each new request»Only works if no state carried from one call to next•What if multiple clients?–Pass pointer to client-specific return mbox in requestLec 25.511/26/08 Kubiatowicz CS162 ©UCB Fall 2008Problems with RPC•Non-Atomic failures–Different failure modes in distributed system than on a single machine–Consider many different types of failures»User-level bug causes address space to crash»Machine failure, kernel bug causes all processes on same machine to fail»Some machine is compromised by malicious party–Before RPC: whole system would crash/die–After RPC: One machine crashes/compromised while others keep working–Can easily result in inconsistent view of the world»Did my cached data get written back or not?»Did server do what I requested or not?–Answer? Distributed transactions/Byzantine Commit•Performance–Cost of Procedure call « same-machine RPC « network RPC–Means programmers must be aware that RPC is not free »Caching can help, but may make failure handling complexLec 25.611/26/08 Kubiatowicz CS162 ©UCB Fall 2008Cross-Domain Communication/Location Transparency•How do address spaces communicate with one another?–Shared Memory with Semaphores, monitors, etc…–File System–Pipes (1-way communication)–“Remote” procedure call (2-way communication)•RPC’s can be used to communicate between address spaces on different machines or the same machine–Services can be run wherever it’s most appropriate–Access to local and remote services looks the same•Examples of modern RPC systems:–CORBA (Common Object Request Broker Architecture)–DCOM (Distributed COM)–RMI (Java Remote Method Invocation)Lec 25.711/26/08 Kubiatowicz CS162 ©UCB Fall 2008Microkernel operating systems•Example: split kernel into application-level servers.–File system looks remote, even though on same machine•Why split the OS into separate domains?–Fault isolation: bugs are more isolated (build a firewall)–Enforces modularity: allows incremental upgrades of pieces of software (client or server)–Location transparent: service can be local or remote»For example in the X windowing system: Each X client can be on a separate machine from X server; Neither has to run on the machine with the frame buffer.App Appfile systemWindowingNetworkingVMThreadsAppMonolithic StructureAppFilesyswindowsRPCaddressspacesthreadsMicrokernel StructureLec 25.811/26/08 Kubiatowicz CS162 ©UCB Fall 2008mountcoeus:/suemountkubi:/progmountkubi:/janeDistributed File Systems•Distributed File System: –Transparent access to files stored on a remote disk•Naming choices (always an issue):–Hostname:localname: Name files explicitly»No location or migration transparency–Mounting of remote file systems»System manager mounts remote file systemby giving name and local mount point»Transparent to user: all reads and writes look like local reads and writes to usere.g. /users/sue/foo/sue/foo on server–A single, global name space: every file in the world has unique name»Location Transparency: servers can change and files can move without involving userNetworkRead FileDataClientServerLec 25.911/26/08 Kubiatowicz CS162 ©UCB Fall 2008Virtual File System (VFS)•VFS: Virtual abstraction similar to local file system–Instead of “inodes” has “vnodes”–Compatible with a variety of local and remote file systems»provides object-oriented way of implementing file systems•VFS allows the same system call interface (the API) to be used for different types of file systems–The API is to the VFS interface, rather than any specific type of file systemLec 25.1011/26/08 Kubiatowicz CS162 ©UCB Fall 2008Simple Distributed File System•Remote Disk: Reads and writes forwarded to server–Use RPC to translate file system calls–No local caching/can be caching at server-side•Advantage: Server provides completely consistent view of file system to multiple clients•Problems? Performance!–Going over network is slower than going to local memory–Lots of network traffic/not well pipelined–Server can be a bottleneckClientServerRead (RPC)Return (Data)ClientWrite


View Full Document

Berkeley COMPSCI 162 - Lecture 25 Distributed File Systems

Documents in this Course
Lecture 1

Lecture 1

12 pages

Nachos

Nachos

41 pages

Security

Security

39 pages

Load more
Download Lecture 25 Distributed File Systems
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture 25 Distributed File Systems and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture 25 Distributed File Systems 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?