Professional Documents
Culture Documents
Outline: File System Consistency Issues in The Presence of Failures
Outline: File System Consistency Issues in The Presence of Failures
Transaction implementation
Transaction implementation (cont’d)
n Key idea: fix problem of how you make multiple updates to disk, by Disk
turning multiple updates into a single disk write! Memory cache
1
Transaction implementation Transaction implementation
(cont’d) (cont’d)
u What if we crash after 1?
n Can we write X back to disk before commit ?
X=1 Y=1 commit
u No commit, nothing on disk, so
just ignore changes
1. Write new value of X to log
n Yes: Keep an “undo log”
u What if we crash after 2? Ditto
2. Write new value of Y to log u What if we crash after 3 before
3. Write commit 4 or 5? n Save old value along with new value
4. Write x to disk u Commit written to log, so replay n If transaction does not commit, “undo change”!
5. Write y to disk those changes back to disk
6. Reclaim space on log
u What if we crash while we are
writing “commit” ?
u As with concurrency, we need
some primitive atomic operation
or else can’t build anything. (e.g.,
writing a single sector on disk is
atomic!)
This eliminates any need for file system check (fsck) after crash
If crash, read log:
n Followed by: remote procedure calls, distributed file
n If log is not complete, no change!
systems
n If log is completely written, apply all changes to disk
2
Log Structured File Systems Motivation (contd.)
n Radical, different approach to designing file systems n File System motivations:
n Disk will run much faster if you use it as a tape drive! n File caches help a reads a lot
File caches do not help writes very much
n Technology motivations: n
n How do you read stuff back from the log? n How do you find Inode-map?
n How do you guarantee there is always free space? n Write into checkpoint memory
3
RAIDs and availability More on RAIDs
n Suppose you need to store more data than fits on a single n Benefits
disk (e.g., large database or file servers). How should n Load gets automatically balanced among disks
arrange data across disks? n Can transfer large file at aggregate bandwidth of all disks
n …………
n If lose any disk, can recover data from other disks plus parity
n Disk1 holds 1001
n Disk2 holds 0101
n Disk3 holds 1000
n Parity disk: 0100
What if we lose disk2? Its contents are parity of remainder!
Thus can lose any disk and data would still be available.
n Updating a disk block needs to update both data and parity --- need to
use write ahead logging to support crash recovery