------------------------------------------------------------------------------
MC logo
File System Consistency
[^] CSc 422
------------------------------------------------------------------------------
[Chapter 1][Chapter 2][Chapter 3][Chapter 4]
[File System Abstraction] [File System Structure] [File System Consistency] [File System Management and Optimization] [Flash Storage] [Examples] [Windows NTFS]
  1. File system changes involve a large number of disk writes.
  2. Creating a file on Unix:
    1. Choose a free data block and update the contents of the free block map to show it is now in use.
    2. Choose a free i-node, then update the i-node map to show it's now in use.
    3. Write the initial contents of the i-node (including a pointer to the data block).
    4. Write a directory entry to refer to the new file.
  3. Other file systems are of similar complexity.
  4. Problem: What if the system crashes half-way through?
    1. The disk operations will generally be at different locations.
    2. Will have to occurs at different times.
    3. The file will be left in a half-created state; some changes made and some not.
  5. When a file system's structures disagree, the file system is inconsistent
    1. If the i-node map is not written, an i-node is both in use and recorded as free. It may end up part of two files, which would be bad.
    2. If the i-node is not initialized, it won't contain a valid link to the data block; all sorts of unpleasant things can happen.
    3. If the directory entry is not written, the file is created, but there is no way to use it.
  6. Amelioration
    1. Some kinds of errors are more serious than others.
    2. Execute the steps in an order, so the errors are less serious.
    3. Update the free lists first, then if there's a crash the error is a block marked used but not.
    4. Initialize the new i-node next.
    5. Update the directory last.
    6. Errors will be limited to wasted resource.
    7. Slows down operation, since disk operations cannot be executed in parallel, or in order to minimize head motion.
  7. File system checkers: How we used to do it.
    1. Run after a system crash.
    2. Traverse the file tree to find all i-nodes, and verify against the bit map.
    3. Likewise, with all data blocks. Also, verify none is used in more than one file
    4. Verify that all files are recorded in a directory.
    5. Unix: fsck; Windows: scandisk
    6. Takes a while.
  8. Current solution: Meta-data journal
    1. The journal is special a region of disk written in rotation.
    2. Before making an update to the file system, a summary is added to the log.
    3. Each log entry is inside a disk sector, so writing it is effectively atomic.
    4. Log entries are collected and written often.
    5. After a crash, the system examines the end of the log. Any partially-completed operations can be completed (or possibly reversed).
    6. Checker available as backup.