1NFS & AFSDave [email protected] Maggsuser id 1915 @ cs.cmu.edu“Good judgment comes from experience… Experience comes from bad judgment.” - attributed to many2SynchronizationWho runs shell? Passes test suite?Who will be around Monday at midnight?TodayNFS, AFSPartially covered by textbook: 12.9, 16.6Chapter 16 is short, why not just read it?3Other Materials UsedNFS: RFC 1094 for v2 (3/1989)RFC 1813 for v3 (6/1995)RFC 3530 for v4 (4/2003)AFS:“The ITC Distributed File System: Principles and Design”, Proceedings of the 10th ACM Symposium on Operating System Principles, Dec. 1985, pp. 35-50.“Scale and Performance in a Distributed File System”, ACM Transactions on Computer Systems, Vol. 6, No. 1, Feb. 1988, pp. 51-81.IBM AFS User Guide, version 36http://www.cs.cmu.edu/~help/afs/index.html4OutlineWhy remote file systems?VFS interceptionNFS vs. AFSArchitectural assumptions & goalsNamespaceAuthentication, access controlI/O flowRough edges5Why?Why remote file systems?Lots of “access data everywhere” technologiesLaptopMulti-gigabyte flash-memory keychain USB devices4G Hitachi MicroDrive fits in a CompactFlash slotiPodAre remote file systems dinosaurs?6Remote File System BenefitsReliabilityNot many people carry multiple copies of dataMultiple copies with you aren't much protectionBackups are niceMachine rooms are niceTemperature-controlled, humidity-controlledFire-suppressedTime travel is nice tooSharingAllows multiple users to access dataMay provide authentication mechanism7Remote File System BenefitsScalabilityLarge disks are cheaperLocality of referenceYou don't use every file every day...Why carry everything in expensive portable storage?AuditabilityEasier to know who said what when with central storage...8What Is A Remote File System?OS-centric viewSomething that supports file-system system calls “for us”Other possible viewsRFS/DFS architect, for exampleMostly out of scope for this classCompared todaySun Microsystems NFSCMU/IBM/Transarc/IBM/Open-Source AFS9VFS interceptionVFS provides “pluggable” file systemsStandard flow of remote accessUser process calls read()Kernel dispatches to VOP_READ() in some VFSnfs_read()check local cachesend RPC to remote NFS serverput process to sleep10VFS interceptionStandard flow of remote access (continued)server interaction handled by kernel processretransmit if necessaryconvert RPC response to file system bufferstore in local cachewake up user processnfs_read()copy bytes to user memory11NFS Assumptions, goalsWorkgroup file systemSmall number of clientsVery small number of serversSingle administrative domainAll machines agree on “set of users”...which users are in which groupsClient machines run mostly-trusted OS“User #37 says read(...)”12NFS Assumptions, goals“Stateless” file serverFiles are “state”, but...Server exports files without creating extra stateNo list of “who has this file open”No “pending transactions” across crashResult: crash recovery “fast”, protocol “simple”Some inherently “stateful” operationsFile lockingHandled by separate service outside of NFS13AFS Assumptions, goalsGlobal distributed file systemUncountable clients, servers“One AFS”, like “one Internet”Why would you want more than one?Multiple administrative domainsusername@cellname[email protected] [email protected] Assumptions, goalsClient machines are un-trustedMust prove they act for a specific userSecure RPC layerAnonymous “system:anyuser”Client machines have disks (!!)Can cache whole files over long periodsWrite/write and write/read sharing are rareMost files updated by one user, on one machine15AFS Assumptions, goalsSupport many clients1000 machines could cache a single fileSome local, some (very) remote16NFS NamespaceConstructed by client-side file system mountsmount server1:/usr/local /usr/localGroup of clients can achieve common namespaceEvery machine executes same mount sequence at bootIf system administrators are diligent17NFS Namespace“Auto-mount” process based on maps/home/dae means server1:/home/dae/home/owens means server2:/home/owens18NFS SecurityClient machine presents credentialsuser #, list of group #s – from Unix processServer accepts or rejects credentials“root squashing”map uid 0 to uid -1 unless client on special machine listKernel process on server “adopts” credentialsSets user #, group vectorMakes system call (e.g., read()) with those credentials19AFS NamespaceAssumed-global list of AFS cellsEverybody sees same files in each cellMultiple servers inside cell invisible to userGroup of clients can achieve private namespaceUse custom cell database20AFS SecurityClient machine presents Kerberos ticketAllows arbitrary binding of (machine,user) to (realm,principal)davide on a cs.cmu.edu machine can be [email protected]iff the password is known!Server checks against access control list21AFS ACLsApply to directory, not to fileFormatde0u rlidwka[email protected] rlde0u:friends rlNegative rightsDisallow “joe rl” even though joe is in de0u:friends22AFS ACLsAFS ACL semantics are not Unix semanticsSome parts obeyed in a vague wayFiles check for being executable, writableMany differencesInherent/good: can name people in different administrative domains“Just different”ACLs are per-directory, not per-fileDifferent privileges: create, remove, lockNot exactly Unix / not tied to Unix23NFS protocol architectureroot@client executes mount RPCreturns “file handle” for root of remote file systemRPC for each pathname component/usr/local/lib/emacs/foo.el in /usr/local file systemh = lookup(root-handle, “lib”)h = lookup(h, “emacs”)h = lookup(h, “foo.el”)Allows disagreement over pathname syntaxLook, Ma, no “/”!24NFS protocol architectureI/O RPCs are idempotentmultiple repetitions have same effect as onelookup(h, “emacs”)read(file-handle, offset, length)write(file-handle, offset, buffer)RPCs do not create server-memory stateno open()/close() RPCwrite()
View Full Document
Unlocking...