15-410 Homework 2

This homework assignment is due Friday, April 29th at 23:59:59. As we intend to make solutions available on the web site immediately thereafter, please turn your solutions in on time. Late days are not available for this assignment.

Homework must be submitted (online) in either PostScript or PDF format (not: Microsoft Word, Word Perfect, Apple Works, LaTeX, XyWrite, WordStar, etc.). A plain text file (.text or .txt) is also acceptable, though it must conform to Unix expectations, meaning lines of no more than 120 characters separated by newline characters (note that this is not the Windows convention, and MacOS has two different conventions). Except as otherwise directed (in the crypto question), turn in your answers as .../$USER/hw2/$USER.pdf, .../$USER/hw2/$USER.ps, or .../$USER/hw2/$USER.text. If you use another filename, there is some risk that your solutions will not be credited to you. Please try not to submit your homework into your book-report directory or the other way around.

As usual, you may discuss this assignment with others, but you must then go off by yourself to write up the solution.

Question 1 - Public Key Practicum

This question is not hard, but it does take some time to do it right. Please don't leave this question to the very last minute, and think carefully about what the various steps accomplish.

As you go through the steps of working on this question, try to think carefully about what each step is accomplishing in terms of underlying cryptography primitives.

Follow the directions in gpg.html to generate a PGP key ring, containing public and private keys for digital signature and encryption purposes. Do not turn the key ring in to your hw2 directory! Instead, follow the directions on how to export the public key information from the key ring into a file, hw2/$USER.asc. Then create a secret message for the course staff, in hw2/$USER.secret.asc.

Question 2 - File-System Transactions

As discussed in lecture, many modern file systems use "journaling" (transactions) so that after a system crash the entire file system can quickly be restored to a state in which the file system's data structures are consistent with the operations in progress at the time of the crash. In other words, after recovery, every system call that was in progress that wanted to modify inodes, directory contents, and/or the free-space map either fully took effect or had no effect.

As also discussed in lecture, most modern file systems do not protect file contents (user data) using transactions.

Part A

Suggest a reason why most modern file systems do not protect file contents using transactions. If possible, suggest a reason that would apply to all files.

Part B

Suggest a reason why most modern file systems do not protect file contents using transactions. If possible, suggest a reason that would apply particularly to large files.

Part C

Now imagine that you are writing an application that will make many small changes within a single large file, and that this large file will be stored in a file system that uses metadata journaling but which does not provide transactional consistency for file contents. In particular, if your application modifies the file with multiple write() system calls, it is possible that the file system would have multiple I/O operations buffered for your file and/or issued to various I/O devices when the system crashes. Explain briefly how your application can protect against the possibility that, after the system restarts, the contents of the large file will be inconsistent.

Helpful Hint

By the way, if you think you are having AFS permission problems, try running the program located at
% /afs/cs.cmu.edu/academic/class/15410-s22/pub/access_hw2

[Last modified Monday April 25, 2022]