Midterm Exam - Stanford Secure Computer Systems Group
Midterm Exam - Stanford Secure Computer Systems Group Midterm Exam - Stanford Secure Computer Systems Group
– p. 14/16 Dealing with crashes • Suppose all data written asynchronously • Delete/truncate a file, append to other file, crash - New file may reuse block from old - Old inode may not be updated - Cross-allocation! - Often inode with older mtime wrong, but can’t be sure • Append to file, allocate indirect block, crash - Inode points to indirect block - But indirect block may contain garbage
– p. 15/16 Ordering of updates • Must be careful about order of updates - Write new inode to disk before directory entry - Remove directory name before deallocating inode - Write cleared inode to disk before updating CG free map • Solution: Many metadata updates syncrhonous - Of course, this hurts performance - E.g., untar much slower than disk b/w • Note: Cannot update buffers on the disk queue
- Page 1 and 2: - p. 1/16 Midterm Exam • Reminder
- Page 3 and 4: - p. 3/16 Original Unix file system
- Page 5 and 6: - p. 5/16 Problems with original FS
- Page 7 and 8: - p. 7/16 FFS superblock • Contai
- Page 9 and 10: - p. 9/16 Inode allocation • Allo
- Page 11 and 12: - p. 11/16 Block allocation • Try
- Page 13: - p. 13/16 Updating FFS for the 90s
– p. 14/16<br />
Dealing with crashes<br />
• Suppose all data written asynchronously<br />
• Delete/truncate a file, append to other file, crash<br />
- New file may reuse block from old<br />
- Old inode may not be updated<br />
- Cross-allocation!<br />
- Often inode with older mtime wrong, but can’t be sure<br />
• Append to file, allocate indirect block, crash<br />
- Inode points to indirect block<br />
- But indirect block may contain garbage
Change language