pintos-os.org Git - pintos-anon/blob - 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 >> B3: Look over "pwd.c" in src/examples.  Briefly explain how it
  78 >> determines the present working directory.
  79
  80 ---- SYNCHRONIZATION ----
  81
  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.
  86
  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?
  91
  92 ---- RATIONALE ----
  93
  94 >> B6: Explain why you chose to represent the current directory of a
  95 >> process the way you did.
  96
  97                              BUFFER CACHE
  98                              ============
  99
 100 ---- DATA STRUCTURES ----
 101
 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.
 105
 106 ---- ALGORITHMS ----
 107
 108 >> C2: Describe how your cache replacement algorithm chooses a cache
 109 >> block to evict.
 110
 111 >> C3: Describe your implementation of write-behind.
 112
 113 >> C4: Describe your implementation of read-ahead.
 114
 115 ---- SYNCHRONIZATION ----
 116
 117 >> C5: When one process is actively reading or writing data in a
 118 >> buffer cache block, how are other processes prevented from evicting
 119 >> that block?
 120
 121 >> C6: During the eviction of a block from the cache, how are other
 122 >> processes prevented from attempting to access the block?
 123
 124 ---- RATIONALE ----
 125
 126 >> C7: Describe a file workload likely to benefit from buffer caching,
 127 >> and workloads likely to benefit from read-ahead and write-behind.
 128
 129                            SURVEY QUESTIONS
 130                            ================
 131
 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
 136 the quarter.
 137
 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?
 140
 141 >> Did you find that working on a particular part of the assignment gave
 142 >> you greater insight into some aspect of OS design?
 143
 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?
 147
 148 >> Do you have any suggestions for the TAs to more effectively assist
 149 >> students in future quarters?
 150
 151 >> Any other comments?