DOC PREVIEW
CMU CS 15410 - Lecture

This preview shows page 1-2-3-20-21-40-41-42 out of 42 pages.

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

Unformatted text preview:

Slide 1Slide 2Slide 3Slide 4Slide 5Slide 6Slide 7Slide 8Slide 9Slide 10Slide 11Slide 12Slide 13Slide 14Slide 15Slide 16Slide 17Slide 18Slide 19Slide 20Slide 21Slide 22Slide 23Slide 24Slide 25Slide 26Slide 27Slide 28Slide 29Slide 30Slide 31Slide 32Slide 33Slide 34Slide 35Slide 36Slide 37Slide 38Slide 39Slide 40Slide 41Slide 421NFS & AFSDave Eckhardtde0u@ andrew.cmu .edu1Synchronization●Lecture Friday: Eno Thereska–Ph.D. student in ECE–Will explain professional disk scheduling●Who runs shell? Passes test suite?–Who will be around Friday midnight?●Today–NFS, AFS–Partially covered by textbook: 12.9, 16.6–Chapter 16 is short, why not just read it?1Outline●Why remote file systems?●VFS interception●NFS &/vs. AFS–Architectural assumptions & goals–Namespace–Authentication, access control–I/O flow–Rough edges1Why?●Why remote file systems?●Lots of “access data everywhere” technologies–Laptop–Multi-gigabyte flash-memory keychain USB devices–4G Hitachi MicroDrive fits in a CompactFlash slot–iPod●Are remote file systems dinosaurs?1Remote File System Benefits●Reliability–Not many people carry multiple copies of data–Multiple copies with you aren't much protection–Backups are nice●Machine rooms are nice–Temperature-controlled, humidty-controlled–Fire-suppressed●Time travel is nice too1Remote File System Benefits●Scalability–Large disks are cheaper●Locality of reference–You don't use every file every day...–Why carry everything in expensive portable storage?●Auditability–Easier to know who said what when with central storage...1What Is A Remote File System?●OS-centric view–Something that supports file-system system calls “for us”●Other possible views–RFS/DFS architect, for example–Mostly out of scope for this class●Compared today–Sun Microsystems NFS–CMU/IBM/Transarc/IBM/Open-Source AFS1VFS interception●VFS provides “pluggable” file systems●Standard flow of remote access–User process calls read()–Kernel dispatches to VOP_READ() in some VFS–nfs_read()●check local cache●send RPC to remote NFS server●put process to sleep1VFS interception●Standard flow of remote access (continued)–server interaction handled by kernel process●retransmit if necessary●convert RPC response to file system buffer●store in local cache●wake up user process–nfs_read()●copy bytes to user memory1NFS Assumptions, goals●Workgroup file system–Small number of clients–Very small number of servers●Single administrative domain–All machines agree on “set of users”●...which users are in which groups–Client machines run mostly-trusted OS●“User #37 says read(...)”1NFS Assumptions, goals●“Stateless” file server–Files are “state”, but...–Server exports files without creating extra state●No list of “who has this file open”●No “pending transactions” across crash–Result: crash recovery “fast”, protocol “simple”●Some inherently “stateful” operations–File locking–Handled by separate service outside of NFS1AFS Assumptions, goals●Global distributed file system–Uncountable clients, servers–“One AFS”, like “one Internet”●Why would you want more than one?●Multiple administrative domains–username@cellname–[email protected] [email protected] Assumptions, goals●Client machines are un-trusted–Must prove they act for a specific user●Secure RPC layer–Anonymous “system:anyuser”●Client machines have disks (!!)–Can cache whole files over long periods●Write/write and write/read sharing are rare–Most files updated by one user, on one machine1AFS Assumptions, goals●Support many clients–1000 machines could cache a single file–Some local, some (very) remote1NFS Namespace●Constructed by client-side file system mounts–mount server1:/usr/local /usr/local●Group of clients can achieve common namespace–Every machine executes same mount sequence at boot–If system administrators are diligent1NFS Namespace●“Auto-mount” process based on maps–/home/dae means server1:/home/dae–/home/owens means server2:/home/owens1NFS Security●Client machine presents credentials–user #, list of group #s – from Unix process●Server accepts or rejects credentials–“root squashing”●map uid 0 to uid -1 unless client on special machine list●Kernel process on server “adopts” credentials–Sets user #, group vector–Makes system call (e.g., read()) with those credentials1AFS Namespace●Assumed-global list of AFS cells●Everybody sees same files in each cell–Multiple servers inside cell invisible to user●Group of clients can achieve private namespace–Use custom cell database1AFS Security●Client machine presents Kerberos ticket–Allows 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 list1AFS ACLs●Apply to directory, not to file●Format–de0u rlidwka–[email protected] rl–de0u:friends rl●Negative rights–Disallow “joe rl” even though joe is in de0u:friends1AFS ACLs●AFS ACL semantics are not Unix semantics–Some parts obeyed in a vague way●Files check for being executable, writable–Many differences●Inherent/good: can name people in different administrative domains●“Just different”–ACLs are per-directory, not per-file–Different privileges: create, remove, lock–Not exactly Unix / not tied to Unix1NFS protocol architecture●root@client executes mount RPC–returns “file handle” for root of remote file system●RPC for each pathname component–/usr/local/lib/emacs/foo.el in /usr/local file system●h = lookup(root-handle, “lib”)●h = lookup(h, “emacs”)●h = lookup(h, “foo.el”)–Allows disagreement over pathname syntax●Look, Ma, no “/”!1NFS protocol architecture●I/O RPCs are idempotent–multiple repetitions have same effect as one–lookup(h, “emacs”)–read(file-handle, offset, length)–write(file-handle, offset, buffer)●RPCs do not create server-memory state–no open()/close() RPC–write() succeeds (to disk) or fails before RPC completes1NFS file handles●Goals–Reasonable size–Quickly map to file on server–“Hard” to forge●Implementation–inode # - small, fast for server–“inode generation #” - must match value stored in inode●(re)initialized to random number1NFS


View Full Document

CMU CS 15410 - Lecture

Download Lecture
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 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 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?