1 +-------------------------+
3 | PROJECT 4: FILE SYSTEMS |
5 +-------------------------+
9 >> Fill in the names and email addresses of your group members.
11 FirstName LastName <email@domain.example>
12 FirstName LastName <email@domain.example>
13 FirstName LastName <email@domain.example>
15 ---- PRELIMINARIES ----
17 >> If you have any preliminary comments on your submission, notes for the
18 >> TAs, or extra credit, please give them here.
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.
24 INDEXED AND EXTENSIBLE FILES
25 ============================
27 ---- DATA STRUCTURES ----
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.
33 >> What is the maximum size of a file supported by your inode structure?
35 ---- SYNCHRONIZATION ----
37 >> Explain how your code avoids a race if two processes attempt to extend
38 >> a file at the same time.
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.
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
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?
64 ---- DATA STRUCTURES ----
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.
72 >> Describe your code for traversing a user-specified path. How do
73 >> traversals of absolute and relative paths differ?
75 >> Look over "pwd.c" in src/examples. Briefly explain how it
76 >> determines the present working directory.
78 ---- SYNCHRONIZATION ----
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.
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
92 >> Explain why you chose to represent the current directory of a process
98 ---- DATA STRUCTURES ----
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.
106 >> Describe how your cache replacement algorithm chooses a cache block to
109 >> Describe your implementation of write-behind.
111 >> Describe your implementation of read-ahead.
113 ---- SYNCHRONIZATION ----
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?
118 >> During the eviction of a block from the cache, how are other processes
119 >> prevented from attempting to access the block?
123 >> Describe a file workload likely to benefit from buffer caching, and
124 >> workloads likely to benefit from read-ahead and write-behind.
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
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?
138 >> Did you find that working on a particular part of the assignment gave
139 >> you greater insight into some aspect of OS design?
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?
145 >> Do you have any suggestions for the TAs to more effectively assist
146 >> students in future quarters?
148 >> Any other comments?