NFS & AFSOutlineWhy?Remote File System BenefitsSlide 5What Is A Remote File System?VFS interceptionSlide 8NFS Assumptions, goalsSlide 10Slide 11AFS Assumptions, goalsSlide 13Slide 14NFS NamespaceSlide 16NFS SecurityAFS NamespaceAFS SecurityAFS ACLsSlide 21NFS protocol architectureSlide 23NFS file handlesNFS Directory OperationsAFS protocol architectureSlide 27AFS CallbacksAFS file identifiersAFS Directory OperationsAFS access patternSlide 32Slide 33Slide 34NFS “rough edges”Slide 36Slide 37AFS “rough edges”Slide 39Slide 40Summary - NFSSummary – AFSFurther ReadingSlide 44NFS & AFSDave [email protected] Maggsuser [email protected]“Good judgment comes from experience… Experience comes from bad judgment.”- attributed to manyOutline●Why remote file systems?●VFS interception●NFS vs. AFS–Architectural assumptions & goals–Namespace–Authentication, access control–I/O flow–Rough edgesWhy?●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?Remote 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, humidity-controlled–Fire-suppressed●Time travel is nice too●Sharing–Allows multiple users to access data–May provide authentication mechanismRemote 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...What 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●Compared today–Sun Microsystems NFS–CMU/IBM/Transarc/IBM/open-source AFSVFS 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 sleepVFS interception●Standard flow of remote access (continued)–client kernel process manages call to server●retransmit if necessary●convert RPC response to file system buffer●store in local cache●wake up user process–back to nfs_read()●copy bytes to user memoryNFS 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(...)”NFS Assumptions, goals●“Stateless” file server–Of course 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”NFS Assumptions, goals●“Stateless” file server–Of course 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 NFS”●Slick trick, eh?AFS 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–Most users on one machine at a timeAFS Assumptions, goals●Support many clients–1000 machines could cache a single file–Some local, some (very) remoteNFS Namespace●Constructed by client-side file system mounts–mount server1:/usr/local /usr/local●Group of clients can achieve common namespace–Every machine can execute same mount sequence at boot–If system administrators are diligentNFS Namespace●“Auto-mount” process based on “maps”–/home/dae means server1:/home/dae–/home/owens means server2:/home/owensNFS 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 based on RPC–Makes system call (e.g., read()) with those credentialsAFS 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 databaseAFS Security●Client machine presents Kerberos ticket–Allows arbitrary binding of (machine,user) to (realm,principal)●bmm on a cs.cmu.edu machine can be [email protected]●iff the password is known!●Server checks against access control listAFS ACLs●Apply to directory, not to individual files●ACL format–bmm rlidwka–[email protected] rl–bmm:friends rl●Negative rights–Disallow “joe rl” even though joe is in bmm:friendsAFS ACLs●AFS ACL semantics are not Unix semantics–Some parts obeyed in a vague way●Cache manager checks for files 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 UnixNFS protocol architecture●root@client executes mount-filesystem RPC–returns “file handle” for root of remote file system●client 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 “/”!NFS protocol architecture●I/O RPCs