CS 161: Operating Systems
Web Work Answers
Below are our solutions to the web work, along with explanations as to why we
think they are correct. Note that some of the questions are ambiguous and can
be interpreted several ways, some of which yield other, equally correct
answers. If you're unsure of your understanding of the material and want to
know whether your answer was also correct, or if you feel like our solution is
incorrect, feel free to reach out to the course staff. However, the web work
is graded only on completion, not on exactly matching the solutions
below, so there's no need to argue your case if you're confident
you're also right.
1. Which of the following pieces of existing code do you expect you will
need to modify in Assignment 4?
2. Which of the following is not necessary to do to use an SFS file
- kern/vm/addrespace.c: We certainly hope not
- kern/fs/sfs/sfs_dir.c: If you want your directory operations to be recoverable,
this is undoubtedly yes.
- kern/fs/sfs/sfs_jphys.c: In theory you shouldn't need to modify this; if you
find yourself wanting to, talk with us -- it suggests that either you're
doing something wrong or we didn't think of some feature jphys should
- kern/vfs/vnode.c: Ideally you should not need to touch this, since the vnode
operations are not specific to a given file system and you are adding
journaling specifically to SFS.
- kern/vfs/buf.c: This probably will need changes to enforce WAL.
- kern/syscall/more_syscalls.c: Yes, you need to interface this to your
file table from assignment 2.
- userland/sbin/mksfs/mksfs.c: If you change the ondisk format for SFS, then
you'll need to change this, but you may not actually need to do that.
3. Prior to adding journaling, SFS maintains consistency via synchronous ordered writes.
False! It doesn't maintain consistency at all.
4. If you unmount an SFS volume and then run sfsck, you should not get
5. 5. Which of the following seem like record types you might need to support in this assignment?
- disk161 create
- dumpsfs (This is a handy debugging tool, but its use is purely optional.)
6. How many different record types can you have in an OS/161 journal?
7. What do we call the unique identifier we use to refer to a log record?
Log Sequence Number, LSN
8. Which of the following are tools or programs that can be used to test
your file system?
sfsck, The DOom Counter, frack, poisondisk are all good test features;
mksfs simply makes a file system, something you'll have to do, but isn't
really a test feature. And crashme isn't a program we give you.
9. New records in jphys appear at the HEAD or the TAIL?
10. Is it possible to use the physical journal provided in OS/161 to
implement multithreaded recovery?
That would be, "No!"
11. Which of the following accurately completes the following
statement: A single journal transaction contains ...
Multiple log records from a single high-level file system operations
12. Assuming UNDO/REDO logging, Which of the following log records
describe idempotent operations?
- Change bit 57 in block 1234 from 0 to 1: This seems like a nice
idempotent way to describe a bitmap change.
- Create a file named foo in directory D: This feels like a high level logical
log record, so, "No!"
- Change the fields in inode 23 from to an initialized
state: This too seems like a nice idempotent way to initialize an inode
- Here is an old copy of block B, here is a new copy of block B: Nah -- this
feels like a low level physical log record.
- Allocate a block: This is too vague
- Here is a block of user data that needs to be written to block 9753: You
don't have to log user data, so probably not.
- Remove the directory entry containing name="dog" inode=825 from slot 3 of this directory.: Ah yes, this too seems like a nice idempotent way of
removing a directory entry.
- Set the first unset bit in the freemap to 1: Not quite -- you don't which
bit is the first unset bit and the freemap might be in a different state
during recovery than it was when you wrote this log record.
- Clear bit 97 in block B: Not quite -- what was the value of bit 97 before
- Create a directory entry in (formerly empty) slot 5 of directory D containing "mynewfile.txt" and inode 123. This seems pretty complete, so yes!
- Mark block 8765 newly allocated in the block bitmap. This too
seems nicely specified
- Remove the directory entry at slot 4 in directory D. That's a little risky;
what if there is a new entry in slot 4?