Page 1 CS162 Operating Systems and Systems Programming Lecture 20 Reliability and Access Control / Distributed Systems April 6, 2010 Ion Stoica http://inst.eecs.berkeley.edu/~cs162 Lec 20.2 4/6/10 CS162 ©UCB Fall 2009 Goals for Today • File Caching • Durability • Authorization • Distributed Systems Note: Some slides and/or pictures in the following are adapted from slides ©2005 Silberschatz, Galvin, and Gagne Note: Some slides and/or pictures in the following are adapted from slides ©2005 Silberschatz, Galvin, and Gagne. Many slides generated from lecture notes by Kubiatowicz. Lec 20.3 4/6/10 CS162 ©UCB Fall 2009 Directory Structure • Not really a hierarchy! – Many systems allow directory structure to be organized as an acyclic graph or even a (potentially) cyclic graph – Hard Links: different names for the same file » Multiple directory entries point at the same file – Soft Links: “shortcut” pointers to other files » Implemented by storing the logical name of actual file • Name Resolution: The process of converting a logical name into a physical resource (like a file) – Traverse succession of directories until reach target file – Global file system: May be spread across the network Lec 20.4 4/6/10 CS162 ©UCB Fall 2009 Directory Structure • Hard link: (“/jim/book/count” inode(count)) – Pro: Reference counting, i.e., when all links are deleted, the file is deleted – Pro: Efficiency, one name resolution step to get inode – Cons: Restricted to same file system • Soft (symbolic) link: (“/jim/book/avi” “/avi/book”) – Pro: Can cross file systems – Cons: Inefficient, multiple name resolution steps – Cons: No reference counting, dangling pointers (e.g., files, directory is deleted)Page 2 Lec 20.5 4/6/10 CS162 ©UCB Fall 2009 Directory Structure (Con’t) • How many disk accesses to resolve “/my/book/count”? – Read in file header for root (fixed spot on disk) – Read in first data block for root » Table of file name/index pairs. Search linearly – ok since directories typically very small – Read in file header for “my” – Read in first data block for “my”; search for “book” – Read in file header for “book” – Read in first data block for “book”; search for “count” – Read in file header for “count” • Current working directory: Per-address-space pointer to a directory (inode) used for resolving file names – Allows user to specify relative filename instead of absolute path (say CWD=“/my/book” can resolve “count”) Lec 20.6 4/6/10 CS162 ©UCB Fall 2009 Where are inodes stored? • In early UNIX and DOS/Windows’ FAT file system, headers stored in special array in outermost cylinders – Header not stored near the data blocks. To read a small file, seek to get header, seek back to data. – Fixed size, set when disk is formatted. At formatting time, a fixed number of inodes were created (They were each given a unique number, called an “inumber”) Lec 20.7 4/6/10 CS162 ©UCB Fall 2009 Where are inodes stored? • Later versions of UNIX moved the header information to be closer to the data blocks – Often, inode for file stored in same “cylinder group” – Cylinder group: one or more consecutive cylinders – Superblock: information about cylinder group, size, number of blocks, etc – Cylinder group map: records the block usage within the cylinder Lec 20.8 4/6/10 CS162 ©UCB Fall 2009 Pros • UNIX BSD 4.2 puts a portion of the file header array on each cylinder. For small directories, can fit all data, file headers, etc in same cylinder⇒no seeks! • File headers much smaller than whole block (a few hundred bytes), so multiple headers fetched from disk at same time • Reliability: whatever happens to the disk, you can find many of the files (even if directories disconnected) • Part of the Fast File System (FFS) – General optimization to avoid seeksPage 3 Lec 20.9 4/6/10 CS162 ©UCB Fall 2009 Linux Example: Ext2/3 Disk Layout • Disk divided into block groups (like cylinder groups) – Provides locality – Each group has two block-sized bitmaps (free blocks/inodes) – Block sizes settable at format time: 1K, 2K, 4K, 8K… • Actual Inode structure similar to 4.2BSD – with 12 direct pointers • Ext3: Ext2 w/Journaling – Several degrees of protection with more or less cost • Example: create a file1.dat under /dir/ in Ext3 Lec 20.10 4/6/10 CS162 ©UCB Fall 2009 • Open system call: – Resolves file name, finds file control block (inode) – Makes entries in per-process and system-wide tables – Returns index (called “file handle”) in open-file table • Read/write system calls: – Use file handle to locate inode – Perform appropriate reads or writes In-Memory File System Structures Lec 20.11 4/6/10 CS162 ©UCB Fall 2009 File System Caching • Key Idea: Exploit locality by caching data in memory – Name translations: Mapping from paths→inodes – Disk blocks: Mapping from block address→disk content • Buffer Cache: Memory used to cache kernel resources, including disk blocks and name translations – Can contain “dirty” blocks (blocks not yet on disk) • Replacement policy? LRU – Can afford overhead of timestamps for each disk block – Advantages: » Works very well for name translation » Works well in general as long as memory is big enough to accommodate a host’s working set of files. – Disadvantages: » Fails when some application scans through file system, thereby flushing the cache with data used only once » Example: find . –exec grep foo {} \; • Other Replacement Policies? – Some systems allow applications to request other policies – Example, ‘Use Once’: » File system can discard blocks as soon as they are used Lec 20.12 4/6/10 CS162 ©UCB Fall 2009 File System Caching (con’t) • Cache Size: How much memory should the OS allocate to the buffer cache vs virtual memory? – Too much memory to the file system cache ⇒ won’t be able to run many applications at once – Too little memory to file system cache ⇒ many applications may run slowly (disk caching not effective) – Solution: adjust boundary dynamically so that the disk access rates
View Full Document
Unlocking...