DOC PREVIEW
Berkeley COMPSCI 162 - Lecture 20 Distributed Systems

This preview shows page 1-2-3 out of 8 pages.

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

Unformatted text preview:

CS162Operating Systems andSystems ProgrammingLecture 20Distributed SystemsNovember 9, 2005Prof. John Kubiatowiczhttp://inst.eecs.berkeley.edu/~cs162Lec 20.211/09/05Kubiatowicz CS162 ©UCB Fall 2005Review: How do we actually access files?• All information about a file contained in its file header– UNIX calls this an “inode”» Inodes are global resources identified by index (“inumber”)– Once you load the header structure, all the other blocks of the file are locatable• Naming: The process by which a system translates from user-visible names to system resources– In the case of files, need to translate from strings (textual names) or icons to inumbers/inodes• 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• Directory: a relation used for naming– Just a table of (file name, inumber) pairs– Directories often stored in files» Reuse of existing mechanism» Directory named by inode/inumber like other filesLec 20.311/09/05Kubiatowicz CS162 ©UCB Fall 2005Goals for Today• File Caching• Data Durability• Distributed SystemsNote: Some slides and/or pictures in the following areadapted from slides ©2005 Silberschatz, Galvin, and Gagne Lec 20.411/09/05Kubiatowicz CS162 ©UCB Fall 2005File 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 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 usedLec 20.511/09/05Kubiatowicz CS162 ©UCB Fall 2005File 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 for paging and file access are balanced• Read Ahead Prefetching: fetch sequential blocks early– Key Idea: exploit fact that most common file access is sequential by prefetching subsequent disk blocks ahead of current read request (if they are not already in memory)– Elevator algorithm can efficiently interleave groups of prefetches from concurrent applications– How much to prefetch?» Too many imposes delays on requests by other applications» Too few causes many seeks (and rotational delays) among concurrent file requestsLec 20.611/09/05Kubiatowicz CS162 ©UCB Fall 2005File System Caching (con’t)• Delayed Writes: Writes to files not immediately sent out to disk– Instead, write() copies data from user space buffer to kernel buffer (in cache)» Enabled by presence of buffer cache: can leave written file blocks in cache for a while» If some other application tries to read data before written to disk, file system will read from cache – Flushed to disk periodically (e.g. in UNIX, every 30 sec)– Advantages: » Disk scheduler can efficiently order lots of requests» Disk allocation algorithm can be run with correct size value for a file» Some files need never get written to disk! (e..g temporary scratch files written /tmp often don’t exist for 30 sec)– Disadvantages» What if system crashes before file has been written out?» Worse yet, what if system crashes before a directory file has been written out? (lose pointer to inode!)Lec 20.711/09/05Kubiatowicz CS162 ©UCB Fall 2005Important “ilities”• Availability: the probability that the system can accept and process requests– Often measured in “nines” of probability. So, a 99.9% probability is considered “3-nines of availability”– Key idea here is independence of failures• Durability: the ability of a system to recover data despite faults– This idea is fault tolerance applied to data– Doesn’t necessarily imply availability: information on pyramids was very durable, but could not be accessed until discovery of Rosetta Stone• Reliability: the ability of a system or component to perform its required functions under stated conditions for a specified period of time (IEEE definition)– Usually stronger than simply availability: means that the system is not only “up”, but also working correctly– Includes availability, security, fault tolerance/durability– Must make sure data survives system crashes, disk crashes, other problemsLec 20.811/09/05Kubiatowicz CS162 ©UCB Fall 2005How to make file system durable?• Disk blocks contain Reed-Solomon error correcting codes (ECC) to deal with small defects in disk drive– Can allow recovery of data from small media defects • Make sure writes survive in short term– Either abandon delayed writes or– use special, battery-backed RAM (called non-volatile RAM or NVRAM) for dirty blocks in buffer cache.• Make sure that data survives in long term– Need to replicate! More than one copy of data!– Important element: independence of failure» Could put copies on one disk, but if disk head fails…» Could put copies on different disks, but if server fails…» Could put copies on different servers, but if building is struck by lightning…. » Could put copies on servers in different continents…• RAID: Redundant Arrays of Inexpensive Disks– Data stored on multiple disks (redundancy)– Either in software or hardware» In hardware case, done by disk controller; file system may not even know that there is more than one disk in useLec 20.911/09/05Kubiatowicz CS162 ©UCB Fall 2005Hardware RAID: Subsystem OrganizationCPUarraycontrollersingle boarddisk controllersingle boarddisk controllersingle boarddisk controllersingle


View Full Document

Berkeley COMPSCI 162 - Lecture 20 Distributed Systems

Documents in this Course
Lecture 1

Lecture 1

12 pages

Nachos

Nachos

41 pages

Security

Security

39 pages

Load more
Download Lecture 20 Distributed 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 20 Distributed 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 20 Distributed 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?