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, lecture notes, and course staff.
  23
  24                      INDEXED AND EXTENSIBLE FILES
  25                      ============================
  26
  27 ---- DATA STRUCTURES ----
  28
  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.
  32
  33 >> A2: What is the maximum size of a file supported by your inode
  34 >> structure?  Show your work.
  35
  36 ---- SYNCHRONIZATION ----
  37
  38 >> A3: Explain how your code avoids a race if two processes attempt to
  39 >> extend a file at the same time.
  40
  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.
  47
  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.
  54
  55 ---- RATIONALE ----
  56
  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?
  62
  63                             SUBDIRECTORIES
  64                             ==============
  65
  66 ---- DATA STRUCTURES ----
  67
  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.
  71
  72 ---- ALGORITHMS ----
  73
  74 >> B2: Describe your code for traversing a user-specified path.  How
  75 >> do traversals of absolute and relative paths differ?
  76
  77 ---- SYNCHRONIZATION ----
  78
  79 >> B4: How do you prevent races on directory entries?  For example,
  80 >> only one of two simultaneous attempts to remove a single file
  81 >> should succeed, as should only one of two simultaneous attempts to
  82 >> create a file with the same name, and so on.
  83
  84 >> B5: Does your implementation allow a directory to be removed if it
  85 >> is open by a process or if it is in use as a process's current
  86 >> working directory?  If so, what happens to that process's future
  87 >> file system operations?  If not, how do you prevent it?
  88
  89 ---- RATIONALE ----
  90
  91 >> B6: Explain why you chose to represent the current directory of a
  92 >> process the way you did.
  93
  94                              BUFFER CACHE
  95                              ============
  96
  97 ---- DATA STRUCTURES ----
  98
  99 >> C1: Copy here the declaration of each new or changed `struct' or
 100 >> `struct' member, global or static variable, `typedef', or
 101 >> enumeration.  Identify the purpose of each in 25 words or less.
 102
 103 ---- ALGORITHMS ----
 104
 105 >> C2: Describe how your cache replacement algorithm chooses a cache
 106 >> block to evict.
 107
 108 >> C3: Describe your implementation of write-behind.
 109
 110 >> C4: Describe your implementation of read-ahead.
 111
 112 ---- SYNCHRONIZATION ----
 113
 114 >> C5: When one process is actively reading or writing data in a
 115 >> buffer cache block, how are other processes prevented from evicting
 116 >> that block?
 117
 118 >> C6: During the eviction of a block from the cache, how are other
 119 >> processes prevented from attempting to access the block?
 120
 121 ---- RATIONALE ----
 122
 123 >> C7: Describe a file workload likely to benefit from buffer caching,
 124 >> and 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?