Answers to reading questions should be written up as a text file (e.g., with emacs or vim or ...) and placed in your handin directory before 9am on the day of the class. The handin directories are found in ~cs739-1/handin/username/hw where username is your CS username. These directories are mounted on all departmental Linux machines. Note that your directory may not yet be there if you are not yet enrolled in class; if so, don't worry, we will figure it out.
File name should follow this format exactly: for question 1, make a file
with the name 1.txt. Of course, the number of the question should change
each time. Thus, to see your work for question 1, I should be able to type:
cat ~cs739-1/handin/username/hw/1.txtand see what you have written - assuming your login is username that is.
Tip #1: Keep it short, say 2-3 paragraphs.
Tip #2: Don't spend time regurgitating obvious stuff from the papers! The point of these questions is to think , and then to write down what it is that you thought about. I read a lot of write-ups, so the more interesting you are, the better! If you find yourself just repeating a lot of details from the paper, you are going down the wrong path.
Tip #3: Don't spend time criticizing how the authors wrote the paper. That is, I don't need to know whether you thought the paper was well written or not. We'll have plenty of time to talk about those types of things later in the class. Focus on technical aspects for these questions.
Q1 (due 9/7 @ 10am): What was the most interesting or important aspect in the Hamilton paper? In the Dean slides? Which aspect of each do you think is least relevant or important today?
Q2 (due 9/12 @ 11am): What aspect of Gray's paper is most correct still today? Which is most wrong? What is the most important result from the Schroeder/Gibson disk failure paper for system designers?
Q3 (due 9/14 @ 11am): Why is kernel emulation of U-Net endpoints needed? What problem does this solve? Are there other ways to overcome this problem that might have better characteristics?
No Question (9/21): Just come to class!
Q4 (due 9/26 @ 11am): What lessons still hold from the Flash and SEDA papers? Which don't? Explain.
Q5 (due 9/28 @ 11am): Which type of vulnerability uncovered by ALICE is least realistic/important? Which is most important and should be addressed by application developers?
No Question (10/3): Because aren't you tired after the warmup project?
Q6 (due 10/5 before class): Describe the trade-offs in setting lease length; what if the time is too short? too long?
Q7 (due 10/10 before class): What kind of faults are handled well by the primary/backup approach as described in the HA-NFS paper? Which types of faults aren't handled well?
No Question (10/12): Just come to the talk.
No Question (10/17): Read paper, work on p2, start thinking about the midterm...
No Question (10/19): Read papers, work on p2, actually start preparing for midterm...
Q8 (due 10/24 before class): Compare Paxos to 2pc. What is similar? What is different?
Q9 (due 10/26 before class): Raft uses a leader-based approach (there is only one leader/proposer at a time), whereas Paxos allows multiple proposers to propose values concurrently. What are the drawbacks of allowing multiple proposers? What are the advantages?
No Question (11/07): Read papers.
Q10 (due 11/9 before class): Consider the performance evaluation of LBFS. What does it show? What doesn't it show? How could you do it better?
Q11 (due 11/19 before class): Describe the strengths and weaknesses of CFS as a file system. What is it good for? What situations should it not be used in?
No Question (11/28): Read the papers. Work on project!
No Question (12/05): Read the paper. Work on project!