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, lecture notes, and course staff.
24 INDEXED AND EXTENSIBLE FILES
25 ============================
27 ---- DATA STRUCTURES ----
29 >> A1: Copy here the declaration of each new or changed `struct' or
30 >> `struct' member, global or static variable, `typedef', or
31 >> enumeration. Identify the purpose of each in 25 words or less.
33 >> A2: What is the maximum size of a file supported by your inode
34 >> structure? Show your work.
36 ---- SYNCHRONIZATION ----
38 >> A3: Explain how your code avoids a race if two processes attempt to
39 >> extend a file at the same time.
41 >> A4: Suppose processes A and B both have file F open, both
42 >> positioned at end-of-file. If A reads and B writes F at the same
43 >> time, A may read all, part, or none of what B writes. However, A
44 >> may not read data other than what B writes, e.g. if B writes
45 >> nonzero data, A is not allowed to see all zeros. Explain how your
46 >> code avoids this race.
48 >> A5: Explain how your synchronization design provides "fairness".
49 >> File access is "fair" if readers cannot indefinitely block writers
50 >> or vice versa. That is, many processes reading from a file cannot
51 >> prevent forever another process from writing the file, and many
52 >> processes writing to a file cannot prevent another process forever
53 >> from reading the file.
57 >> A6: Is your inode structure a multilevel index? If so, why did you
58 >> choose this particular combination of direct, indirect, and doubly
59 >> indirect blocks? If not, why did you choose an alternative inode
60 >> structure, and what advantages and disadvantages does your
61 >> structure have, compared to a multilevel index?
66 ---- DATA STRUCTURES ----
68 >> B1: Copy here the declaration of each new or changed `struct' or
69 >> `struct' member, global or static variable, `typedef', or
70 >> enumeration. Identify the purpose of each in 25 words or less.
74 >> B2: Describe your code for traversing a user-specified path. How
75 >> do traversals of absolute and relative paths differ?
77 >> B3: Look over "pwd.c" in src/examples. Briefly explain how it
78 >> determines the present working directory.
80 ---- SYNCHRONIZATION ----
82 >> B4: How do you prevent races on directory entries? For example,
83 >> only one of two simultaneous attempts to remove a single file
84 >> should succeed, as should only one of two simultaneous attempts to
85 >> create a file with the same name, and so on.
87 >> B5: Does your implementation allow a directory to be removed if it
88 >> is open by a process or if it is in use as a process's current
89 >> working directory? If so, what happens to that process's future
90 >> file system operations? If not, how do you prevent it?
94 >> B6: Explain why you chose to represent the current directory of a
95 >> process the way you did.
100 ---- DATA STRUCTURES ----
102 >> C1: Copy here the declaration of each new or changed `struct' or
103 >> `struct' member, global or static variable, `typedef', or
104 >> enumeration. Identify the purpose of each in 25 words or less.
108 >> C2: Describe how your cache replacement algorithm chooses a cache
111 >> C3: Describe your implementation of write-behind.
113 >> C4: Describe your implementation of read-ahead.
115 ---- SYNCHRONIZATION ----
117 >> C5: When one process is actively reading or writing data in a
118 >> buffer cache block, how are other processes prevented from evicting
121 >> C6: During the eviction of a block from the cache, how are other
122 >> processes prevented from attempting to access the block?
126 >> C7: Describe a file workload likely to benefit from buffer caching,
127 >> and workloads likely to benefit from read-ahead and write-behind.
132 Answering these questions is optional, but it will help us improve the
133 course in future quarters. Feel free to tell us anything you
134 want--these questions are just to spur your thoughts. You may also
135 choose to respond anonymously in the course evaluations at the end of
138 >> In your opinion, was this assignment, or any one of the three problems
139 >> in it, too easy or too hard? Did it take too long or too little time?
141 >> Did you find that working on a particular part of the assignment gave
142 >> you greater insight into some aspect of OS design?
144 >> Is there some particular fact or hint we should give students in
145 >> future quarters to help them solve the problems? Conversely, did you
146 >> find any of our guidance to be misleading?
148 >> Do you have any suggestions for the TAs to more effectively assist
149 >> students in future quarters?
151 >> Any other comments?