Skip to main content
Contents Dark Mode Prev Up Next Profile \(\newcommand{\N}{\mathbb N} \newcommand{\Z}{\mathbb Z} \newcommand{\Q}{\mathbb Q} \newcommand{\R}{\mathbb R}
\newcommand{\lt}{<}
\newcommand{\gt}{>}
\newcommand{\amp}{&}
\definecolor{fillinmathshade}{gray}{0.9}
\newcommand{\fillinmath}[1]{\mathchoice{\colorbox{fillinmathshade}{$\displaystyle \phantom{\,#1\,}$}}{\colorbox{fillinmathshade}{$\textstyle \phantom{\,#1\,}$}}{\colorbox{fillinmathshade}{$\scriptstyle \phantom{\,#1\,}$}}{\colorbox{fillinmathshade}{$\scriptscriptstyle\phantom{\,#1\,}$}}}
\)
Section 5.5 Consistency: FSCK and Journaling
Practice 5.5.1 .
When trying to write to a disk, which of the following problems do we want to avoid as a result of a power loss?
We’ve added the contents of a new file, but not the directory that lists the file.
We’ve added the contents of a new file, but didn’t update the parent directory that should list the file.
We’ve updated the contents and size of a file, but the inode still shows the old information.
We have written new file contents in a block but did not update the block bitmap to mark the block as used.
We have not added the file we were trying to add or any information about it.
Practice 5.5.2 .
The book discusses a simple example of trying to write a new block to a file. It consisted of 3 updates that need to happen:
A: The data block Db contents are written
B: The inode is updated to include a pointer to the new block
C: The block bitmap is updated to mark the block as in use
If all three happen then we are OK. Also if none of them happen we are also OK from the point of view of consistency. Each of the other situations needs some thought, match them to the following end states.
Only A happens
There is a block not referenced anywhere. No real harm done.
Only B happens
An inode pointer now points to garbage. When reading the file we will get back non-sense.
Only C happens
A block is marked as in use but is not actually used. We are leaking space.
Only A and B happen
The file appears fine for now. But the new block is not marked as in use and it might be overwritten with different data in the future.
Only A and C happen
Same problem as the case with only C.
Only B and C happen
Same problem as the case with only B.
Practice 5.5.3 .
Match the following terms of inconsistent states to their definitions.
A inode points to a data block but the bitmap says the block is available.
file-system inconsistency
The bitmap says a block is available but no inode references it.
space leak
Read section 42.4 about the FSCK solution to the crash consistency problem.
Practice 5.5.4 .
True or False: FSCK prevents crash inconsistencies from happening in the first place.
True.
No, FSCK aims to fix the inconsistency when the system reboots.
False.
No, FSCK aims to fix the inconsistency when the system reboots.
Practice 5.5.5 .
Practice 5.5.6 .
What kinds of checks does FSCK do?
The size of the system as declared in the superblock is more than the number of reported blocks.
If an inode points to a block, we make sure the block bitmap for that block is marked.
If an inode is listed in directory contents, we make sure the inode bitmap for that inode is is marked.
The link count of allocated inodes is verified to match the number of directories linking to them.
Inodes that are not linked to by any directory are moved to a special directory.
If two inodes refer to the same block.
If there are any typos in user-stored data, they are corrected.
If files are marked as having the wrong format (e.g. text vs image), this is rectified.
Practice 5.5.7 .
What are the main drawbacks of FSCK?
It is slow as it tries to check everything.
It may not find the problems.
It can only run while the file system is inactive.
Read section 42.3 about the journaling (write-ahead logging) approach to dealing with crash-inconsistencies.
Practice 5.5.8 .
Practice 5.5.9 .
What are the two stages of a journaling setup?
journal write
We record in the journal the details of what we are about to write (but without the transaction-end block).
journal commit
We record end-of-transaction in the journal, to finalize a prepared transaction.
checkpoint
We change the actual file system areas based on the info in a journal transaction.
Practice 5.5.10 .
Practice 5.5.11 .
True or False: With disk write-buffering, requested writes may occur in an order different than the one intended, with a possible crash resulting in a case where a sequence of two writes A-B may result in only the second write happening.
True.
False.
Practice 5.5.12 .
What is
ordered journaling ?
When we only record metadata information in the log, while the user data is written directly to disk.
When transactions in the log are written in order one after the other and not circling back.
When we keep the log nice and tidy.
Read section 42.4 about other approaches, and section 42.5 about a brief summary.
You have attempted
of
activities on this page.
