CS 423 Operating System Design: Reliable Storage Professor Adam Bates CS 423: Operating Systems Design
Storage is hard ; - ( “In each cluster's first year, it's typical that 1,000 individual machine failures will occur; thousands of hard drive failures will occur ; one power distribution unit will fail, bringing down 500 to 1,000 machines for about 6 hours; 20 racks will fail, each time causing 40 to 80 machines to vanish from the network; 5 racks will "go wonky," with half their network packets missing in action; and the cluster will have to be rewired once, affecting 5 percent of the machines at any given moment over a 2-day span, Dean said. And there's about a 50 percent chance that the cluster will overheat, taking down most of the servers in less than 5 minutes and taking 1 to 2 days to recover.” - Jeff Dean, Google Fellow (2008) CS 423: Operating Systems Design 2
Transaction Concept A transaction is a grouping of low-level operations that are related to a single ■ logical operation Transactions are atomic — operations appear to happen as a group, or not at ■ all (at logical level) At physical level of course, only a single disk/flash write is atomic ■ Transactions are durable — operations that complete stay completed ■ Future failures do not corrupt previously stored data ■ (In-Progress) Transactions are isolated — other transactions cannot see the ■ results of earlier transactions until they are committed Transactions exhibit consistency — sequential memory model ■ CS 423: Operating Systems Design 3
Reliability Attempt #1: Careful Ordering Sequence operations in a specific order ■ Careful design to allow sequence to be interrupted safely ■ Post-crash recovery ■ Read data structures to see if there were any operations in progress ■ Clean up/finish as needed ■ Approach taken in FAT, FFS (fsck), and many app-level ■ recovery schemes (e.g., Word) CS 423: Operating Systems Design 4
Reliability Attempt #1: Careful Ordering FAT: Append Data to File MFT Data Blocks Add data block ■ 0 1 Add pointer to data block ■ 2 3 fj le 9 block 3 Update file tail to point to ■ 4 5 new MFT entry 6 7 Update access time at ■ 8 9 fj le 9 block 0 head of file 10 fj le 9 block 1 11 fj le 9 block 2 Recovery fj le 12 block 0 12 13 Scan MFT ■ 14 15 If entry is unlinked, delete 16 fj le 12 block 1 ■ 17 data block 18 fj le 9 block 4 19 If access time is incorrect, ■ 20 update CS 423: Operating Systems Design 5
Reliability Attempt #1: Careful Ordering FFS: Create New File Allocate data block Inode Array Triple Double ■ Indirect Indirect Indirect Write data block ■ Inode Blocks Blocks Blocks Allocate inode ■ Write inode block ■ Update bitmap of free blocks ■ File Metadata Update directory with ■ file name -> file number Direct Pointer DP Update modify time for directory ■ DP DP DP Recovery DP Scan inode table DP ■ DP If any unlinked files (not in any ■ DP directory), delete DP DP Compare free block bitmap against inode ■ Direct Pointer trees Indirect Pointer Dbl. Indirect Ptr. Scan directories for missing update/ ■ Tripl. Indirect Ptr. access times Recovery time is proportional to size of disk! CS 423: Operating Systems Design 6
Reliability Attempt #1: Careful Ordering FFS: Move a File Inode Array Triple Double Remove filename from old ■ Indirect Indirect Indirect directory Inode Blocks Blocks Blocks Add filename to new directory ■ File Metadata Direct Pointer DP DP DP DP DP DP DP DP DP DP Direct Pointer Indirect Pointer Dbl. Indirect Ptr. Tripl. Indirect Ptr. CS 423: Operating Systems Design 7
Reliability Attempt #1: Careful Ordering Application Level Write name of each open file to ■ app folder Write changes to backup file ■ Rename backup file to be file ■ (atomic operation provided by file system) Delete list in app folder on clean ■ shutdown Recovery On startup, see if any files were ■ left open If so, look for backup file ■ If so, ask user to compare ■ versions CS 423: Operating Systems Design 8
Reliability Attempt #1: Careful Ordering FFS: Move and Grep Observation — careful ordering is not a panacea… ■ Process A moves file from x to y mv x/file y/ Process B greps across x and y grep x/* y/* Will Process B always see the contents of the file? ■ CS 423: Operating Systems Design 9
Reliability Attempt #1: Careful Ordering Pros Works with minimal support from the disk drive ■ Works for most multi-step operations ■ Cons Can require time-consuming recovery after a failure ■ Difficult to reduce every operation to a safely-interruptible ■ sequence of writes Difficult to achieve consistency when multiple operations ■ occur concurrently (e.g., FFS grep) CS 423: Operating Systems Design 10
Reliability Attempt #2: Copy-on-Write To update file system, write a new version of the file system ■ containing the update ■ Never update in place ■ Reuse existing unchanged disk blocks Seems expensive! But… ■ ■ Updates can be batched ■ Almost all disk writes can occur in parallel Approach taken in network file server appliances (WAFL, ZFS) ■ CS 423: Operating Systems Design 11
Reliability Attempt #2: Copy-on-Write Copy on Write (Write Anywhere File Layout) Root Inode Inode File’s Inode Array Indirect Data Root Inode Inode File’s Inode Array Indirect Data Slots Indirect Blocks (in Inode File) Blocks Blocks Slots Indirect Blocks (in Inode File) Blocks Blocks Update Last Block of File Fixed Anywhere Location CS 423: Operating Systems Design 12
Reliability Attempt #2: Copy-on-Write Batch Updates Root Root Inode File’s File’s Inode Inode’s File Indirect Data Indirect Blocks Blocks Blocks New Indirect New Nodes Root Inode New New Indirect Data Nodes of Block of Inode New Inode File Data File Blocks CS 423: Operating Systems Design 13
Reliability Attempt #2: Copy-on-Write Pros Correct behavior regardless of failures ■ Fast recovery (root block array) ■ High throughput (best if updates are batched) ■ Cons Potential for high latency ■ Small changes require many writes ■ Garbage collection essential for performance ■ CS 423: Operating Systems Design 14
Logging File Systems Instead of modifying data structures on disk directly, write ■ changes to a journal/log ■ Intention list: set of changes we intend to make ■ Log/Journal is append-only Once changes are on log, safe to apply changes to data ■ structures on disk ■ Recovery can read log to see what changes were intended Once changes are copied, safe to remove log ■ CS 423: Operating Systems Design 15
Redo Logging Prepare Recovery ■ ■ Write all changes (in Read log ■ ■ transaction) to log Redo any operations for ■ Commit committed transactions ■ Garbage collect log Single disk write to make ■ ■ transaction durable Redo / Write Back ■ Copy changes to disk ■ Garbage collection ■ Reclaim space in log ■ CS 423: Operating Systems Design 16
Redo Logging Before transaction start Cache Tom = $200 Mike = $100 Tom = $200 Mike = $100 Nonvolatile Storage Log: CS 423: Operating Systems Design 17
Redo Logging After Updates are Logged Cache Tom = $100 Mike = $200 Tom = $200 Mike = $100 Nonvolatile Storage Log: Tom = $100 Mike = $200 CS 423: Operating Systems Design 18
Redo Logging After commit logged Cache Tom = $100 Mike = $200 Tom = $200 Mike = $100 Nonvolatile Storage COMMIT Log: Tom = $100 Mike = $200 CS 423: Operating Systems Design 19
Redo Logging After write back Cache Tom = $100 Mike = $200 Tom = $100 Mike = $200 Nonvolatile Storage COMMIT Log: Tom = $100 Mike = $200 COMMIT CS 423: Operating Systems Design 20
Redo Logging After garbage collection Cache Tom = $100 Mike = $200 Tom = $100 Mike = $200 Nonvolatile Storage Log: CS 423: Operating Systems Design 21
Redo Logging Questions What happens if machine crashes… ■ ■ Before transaction start? ■ After transaction start, before operations are logged? ■ After operations are logged, before commit? ■ After commit, before write back? ■ After write back before garbage collection? What happens if machine crashes during recovery? ■ CS 423: Operating Systems Design 22
Redo Logging Performance Log written sequentially ■ ■ Often kept in flash storage Asynchronous write back ■ ■ Any order as long as all changes are logged before commit, and all write backs occur after commit Can process multiple transactions ■ ■ Transaction ID in each log entry ■ Transaction completed iff its commit record is in log CS 423: Operating Systems Design 23
Transaction Isolation What if grep starts after changes are logged but before they ■ are commited? Process A moves file from x to y Process B greps across x and y mv x/file y/ grep x/* y/* CS 423: Operating Systems Design 24
Recommend
More recommend
