File system project updates:
[pintos-anon] / doc / filesys.tmpl
1                      +-------------------------+
2                      |          CS 140         |
3                      | PROJECT 4: FILE SYSTEMS |
4                      |     DESIGN DOCUMENT     |
5                      +-------------------------+
6
7 ---- GROUP ----
8
9 >> Fill in the names and email addresses of your group members.
10
11 FirstName LastName <email@domain.example>
12 FirstName LastName <email@domain.example>
13 FirstName LastName <email@domain.example>
14
15 ---- PRELIMINARIES ----
16
17 >> If you have any preliminary comments on your submission, notes for the
18 >> TAs, or extra credit, please give them here.
19
20 >> Please cite any offline or online sources you consulted while
21 >> preparing your submission, other than the Pintos documentation, course
22 >> text, and lecture notes.
23
24                      INDEXED AND EXTENSIBLE FILES
25                      ============================
26
27 ---- DATA STRUCTURES ----
28
29 >> Copy here the declaration of each new or changed `struct' or `struct'
30 >> member, global or static variable, `typedef', or enumeration.
31 >> Identify the purpose of each in 25 words or less.
32
33 >> What is the maximum size of a file supported by your inode structure?
34
35 ---- SYNCHRONIZATION ----
36
37 >> Explain how your code avoids a race if two processes attempt to extend
38 >> a file at the same time.
39
40 >> Suppose processes A and B both have file F open, both positioned at
41 >> end-of-file.  If A reads and B writes F at the same time, A may read
42 >> all, part, or none of what B writes.  However, A may not read data
43 >> other than what B writes, e.g. if B writes nonzero data, A is not
44 >> allowed to see all zeros.  Explain how your code avoids this race.
45
46 >> Explain how your synchronization design provides "fairness".  File
47 >> access is "fair" if readers cannot indefinitely block writers or vice
48 >> versa.  That is, many processes reading from a file cannot prevent
49 >> forever another process from writing the file, and many processes
50 >> writing to a file cannot prevent another process forever from reading
51 >> the file.
52
53 ---- RATIONALE ----
54
55 >> Is your inode structure a multilevel index?  If so, why did you choose
56 >> this particular combination of direct, indirect, and doubly indirect
57 >> blocks?  If not, why did you choose an alternative inode structure,
58 >> and what advantages and disadvantages does your structure have,
59 >> compared to a multilevel index?
60
61                             SUBDIRECTORIES
62                             ==============
63
64 ---- DATA STRUCTURES ----
65
66 >> Copy here the declaration of each new or changed `struct' or `struct'
67 >> member, global or static variable, `typedef', or enumeration.
68 >> Identify the purpose of each in 25 words or less.
69
70 ---- ALGORITHMS ----
71
72 >> Describe your code for traversing a user-specified path.  How do
73 >> traversals of absolute and relative paths differ?
74
75 >> Look over "pwd.c" in src/examples.  Briefly explain how it
76 >> determines the present working directory.
77
78 ---- SYNCHRONIZATION ----
79
80 >> How do you prevent races on directory entries?  For example, only one
81 >> of two simultaneous attempts to remove a single file should succeed,
82 >> as should only one of two simultaneous attempts to create a file with
83 >> the same name, and so on.
84
85 >> Does your implementation allow a directory to be removed if it is in
86 >> use as a process's current directory?  If so, what happens to that
87 >> process's future file system operations?  If not, how do you prevent
88 >> it?
89
90 ---- RATIONALE ----
91
92 >> Explain why you chose to represent the current directory of a process
93 >> the way you did.
94
95                              BUFFER CACHE
96                              ============
97
98 ---- DATA STRUCTURES ----
99
100 >> Copy here the declaration of each new or changed `struct' or `struct'
101 >> member, global or static variable, `typedef', or enumeration.
102 >> Identify the purpose of each in 25 words or less.
103
104 ---- ALGORITHMS ----
105
106 >> Describe how your cache replacement algorithm chooses a cache block to
107 >> evict.
108
109 >> Describe your implementation of write-behind.
110
111 >> Describe your implementation of read-ahead.
112
113 ---- SYNCHRONIZATION ----
114
115 >> When one process is actively reading or writing data in a buffer cache
116 >> block, how are other processes prevented from evicting that block?
117
118 >> During the eviction of a block from the cache, how are other processes
119 >> prevented from attempting to access the block?
120
121 ---- RATIONALE ----
122
123 >> Describe a file workload likely to benefit from buffer caching, and
124 >> workloads likely to benefit from read-ahead and write-behind.
125
126                            SURVEY QUESTIONS
127                            ================
128
129 Answering these questions is optional, but it will help us improve the
130 course in future quarters.  Feel free to tell us anything you
131 want--these questions are just to spur your thoughts.  You may also
132 choose to respond anonymously in the course evaluations at the end of
133 the quarter.
134
135 >> In your opinion, was this assignment, or any one of the three problems
136 >> in it, too easy or too hard?  Did it take too long or too little time?
137
138 >> Did you find that working on a particular part of the assignment gave
139 >> you greater insight into some aspect of OS design?
140
141 >> Is there some particular fact or hint we should give students in
142 >> future quarters to help them solve the problems?  Conversely, did you
143 >> find any of our guidance to be misleading?
144
145 >> Do you have any suggestions for the TAs to more effectively assist
146 >> students in future quarters?
147
148 >> Any other comments?