DOC PREVIEW
Berkeley COMPSCI 162 - Lecture 24 Distributed File Systems

This preview shows page 1-2-3-26-27-28 out of 28 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 28 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 28 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 28 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 28 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 28 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 28 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 28 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

CS162 Operating Systems and Systems Programming Lecture 24 Distributed File SystemsReview: Network CommunicationReview: Distributed ApplicationsReview: Byzantine General’s ProblemReview: Byzantine General’s Problem (con’t)Review: Remote Procedure CallGoals for TodayRPC Information FlowRPC DetailsRPC Details (continued)Problems with RPCAdministriviaCross-Domain Communication/Location TransparencyMicrokernel operating systemsDistributed File SystemsVirtual File System (VFS)Simple Distributed File SystemUse 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)ConclusionCS162Operating Systems andSystems ProgrammingLecture 24Distributed File SystemsNovember 23, 2005Prof. John Kubiatowiczhttp://inst.eecs.berkeley.edu/~cs162Lec 24.211/23/05 Kubiatowicz CS162 ©UCB Fall 2005Review: Network Communication•TCP: Reliable byte stream between two processes on different machines over Internet (read, write, flush)•Socket: an abstraction of a network I/O queue–Embodies one side of a communication channel»Same interface regardless of location of other end»Could be local machine (called “UNIX socket”) or remote machine (called “network socket”)•Two-phase commit: distributed decision making–First, make sure everyone guarantees that they will commit if asked (prepare)–Next, ask everyone to commitServerSocketsocket socketconnectionRequest ConnectionnewsocketServerClientLec 24.311/23/05 Kubiatowicz CS162 ©UCB Fall 2005Review: Distributed Applications•Message Abstraction: send/receive messages–Already atomic: no receiver gets portion of a message and two receivers cannot get same message•Interface:–Mailbox (mbo x): temporary holding area for messages»Includes both destination location and queue–Send(message, mbox)»Send message to remote mailbox identified by mb o x–Receive(buffe r,mbox)»Wait until mbox has message, copy into buffer, and return»If threads sleeping on this mbox, wake up one of themNetworkSendReceiveLec 24.411/23/05 Kubiatowicz CS162 ©UCB Fall 2005Review: Byzantine General’s Problem•Byazantine General’s Problem (n players):–One General–n-1 Lieutenants–Some number of these (f<n/3) can be insane or malicious•The commanding general must send an order to his n-1 lieutenants such that:–IC1: All loyal lieutenants obey the same order–IC2: If the commanding general is loyal, then all loyal lieutenants obey the order he sendsGeneralAttack!Attack!Attack!Retreat!Attack!Retreat!Attack!Attack!Attack!LieutenantLieutenantLieutenantMalicious!Lec 24.511/23/05 Kubiatowicz CS162 ©UCB Fall 2005Review: Byzantine General’s Problem (con’t)•Impossibility Results:–Cannot solve Byzantine General’s Problem with n=3 because one malicious player can mess up things–With f faults, need n > 3f to solve problem•Various algorithms exist to solve problem–Original algorithm has #messages exponential in n–Newer algorithms have message complexity O(n2)»One from MIT, for instance (Castro and Liskov, 1999)•Use of BFT (Byzantine Fault Tolerance) algorithm–Allow multiple machines to make a coordinated decision even if some subset of them (< n/3 ) are maliciousGeneralLieutenantLieutenantAttack! Attack!Retreat!GeneralLieutenantLieutenantAttack! Retreat!Retreat!RequestDistributedDecisionLec 24.611/23/05 Kubiatowicz CS162 ©UCB Fall 2005Review: Remote Procedure Call•Raw messaging is a bit too low-level for programming–Must wrap up information into message at source–Must decide what to do with message at destination–May need to sit and wait for multiple messages to arrive•Better option: Remote Procedure Call (RPC)–Calls a procedure on a remote machine–Client calls: remoteFileSystemRead(“rutabaga”);–Translated automatically into call on server:fileSysRead(“rutabaga”);•Implementation:–Request-response message passing (under covers!)–“Stub” provides glue on client/server»Client stub is responsible for “marshalling” arguments and “unmarshalling” the return values»Server-side stub is responsible for “unmarshalling” arguments and “marshalling” the return values.•Marshalling involves (depending on system)–Converting values to a canonical form, serializing objects, copying arguments passed by reference, etc.Lec 24.711/23/05 Kubiatowicz CS162 ©UCB Fall 2005Goals for Today•Finish RPC•Examples of Distributed File Systems•Cache Coherence ProtocolsNote: Some slides and/or pictures in the following areadapted from slides ©2005 Silberschatz, Galvin, and GagneLec 24.811/23/05 Kubiatowicz CS162 ©UCB Fall 2005RPC Information FlowClient(caller)Server(callee)PacketHandlerPacketHandlercallreturnsendreceivesendreceivereturncallNetworkNetworkClientStubbundleargsbundleret valsunbundleret valsServerStubunbundleargsMachine AMachine Bmbox1mbox2Lec 24.911/23/05 Kubiatowicz CS162 ©UCB Fall 2005RPC Details•Equivalence with regular procedure call–Parameters Request Message–Result  Reply message–Name of Procedure: Passed in request message–Return Address: mbox2 (client return mail box) •Stub generator: Compiler that generates stubs–Input: interface definitions in an “interface definition language (IDL)”»Contains, among other things, types of arguments/return–Output: stub code in the appropriate source language»Code for client to pack message, send it off, wait for result, unpack result and return to caller»Code for server to unpack message, call procedure, pack results, send them off•Cross-platform issues:–What if client/server machines are different architectures or in different languages?»Convert everything to/from some canonical form»Tag every item with an indication of how it is encoded (avoids unnecessary conversions).Lec 24.1011/23/05 Kubiatowicz CS162 ©UCB Fall 2005RPC 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 dynmaic translation of servicembox–Why dynamic


View Full Document

Berkeley COMPSCI 162 - Lecture 24 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 24 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 24 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 24 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?