Filesystem Consistency
In-Class Activity
FSCK
-
All metadata updates are done in a predefined global order
-
Metadata updates are made via write-through caching--every write makes it to disk before the next operation can start.
- On crash, examine the filesystem to see if anything is inconsistent, and apply appropriate fixups if inconsistency is found.
Filesystem Detective
I have snapshots of several filesystems which crashed mid-update.
We happen to know that they used an fsck-like procedure to do file creations, and an informant has told us what global order of operations they used for file updates. We also suspect that all the filesystems involved were creating a new file when they crashed.
Your job: examine these snapshots and determine the following:
- Is it in an inconsistent state?
- If so, where were it in the file creation process when the power was interrupted?
- How much information can we recover?
The system is a direct-allocated filesystem using bitmap tracking and a single global directory.
Ø is a null pointer. Uncolored inodes have all their pointers set to Ø.
Update order:
- Data Block
- Inode
- Inode Bitmap
- Data Bitmap
- Directory
- Is it in an inconsistent state?
- If so, where were it in the file creation process when the power was interrupted?
- If applicable, how much information can we recover?
System 1
System 2
System 3
System 4
Blocks are zero-indexed (careful with orange/purple block!)
Solutions
System 1
Update order:
- Data Block
- Inode
- Inode Bitmap
- Data Bitmap
- Directory
Consistent!
Question: did it feel easy?
System 2
Update order:
- Data Block
- Inode
- Inode Bitmap
- Data Bitmap
- Directory
Inconsistency: file 9 is not in the directory
...but its other data/metadata is intact! This must have failed after the data bitmap update and before the directory update.
We can recover everything about the file except for its name.
System 3
Update order:
- Data Block
- Inode
- Inode Bitmap
- Data Bitmap
- Directory
Inconsistency: file 3 is not in the directory
Inconsistency: file 3 points to blocks D4 and D5, but they are not marked as used in the bitmap.
The inodes are marked as used in the inode bitmap, so this must have failed between inodde and data bitmap updates.
We can recover everything about the file except for its name.
System 4
Update order:
- Data Block
- Inode
- Inode Bitmap
- Data Bitmap
- Directory
Something is funny about file 1...
- It's not in the directory
- It's inode isn't allocated
- It's data block isn't allocated
What happened here?
Two possibilities:
- We failed after writing inode but before updating bitmaps.
- We deleted the file by unsetting its data + inode bitmaps!
Conclusion: failing before inode bitmap update is the same as failing in first two steps: looks like file creation never happened.