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, 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 ---- SYNCHRONIZATION ----
  76
  77 >> How do you prevent races on directory entries?  For example, only one
  78 >> of two simultaneous attempts to remove a single file should succeed,
  79 >> as should only one of two simultaneous attempts to create a file with
  80 >> the same name, and so on.
  81
  82 >> Does your implementation allow a directory to be removed if it is in
  83 >> use as a process's current directory?  If so, what happens to that
  84 >> process's future file system operations?  If not, how do you prevent
  85 >> it?
  86
  87 ---- RATIONALE ----
  88
  89 >> Explain why you chose to represent the current directory of a process
  90 >> the way you did.
  91
  92                              BUFFER CACHE
  93                              ============
  94
  95 ---- DATA STRUCTURES ----
  96
  97 >> Copy here the declaration of each new or changed `struct' or `struct'
  98 >> member, global or static variable, `typedef', or enumeration.
  99 >> Identify the purpose of each in 25 words or less.
 100
 101 ---- ALGORITHMS ----
 102
 103 >> Describe how your cache replacement algorithm chooses a cache block to
 104 >> evict.
 105
 106 >> Describe your implementation of write-behind.
 107
 108 >> Describe your implementation of read-ahead.
 109
 110 ---- SYNCHRONIZATION ----
 111
 112 >> When one process is actively reading or writing data in a buffer cache
 113 >> block, how are other processes prevented from evicting that block?
 114
 115 >> During the eviction of a block from the cache, how are other processes
 116 >> prevented from attempting to access the block?
 117
 118 ---- RATIONALE ----
 119
 120 >> Describe a file workload likely to benefit from buffer caching, and
 121 >> workloads likely to benefit from read-ahead and write-behind.
 122
 123                            SURVEY QUESTIONS
 124                            ================
 125
 126 Answering these questions is optional, but it will help us improve the
 127 course in future quarters.  Feel free to tell us anything you
 128 want--these questions are just to spur your thoughts.  You may also
 129 choose to respond anonymously in the course evaluations at the end of
 130 the quarter.
 131
 132 >> In your opinion, was this assignment, or any one of the three problems
 133 >> in it, too easy or too hard?  Did it take too long or too little time?
 134
 135 >> Did you find that working on a particular part of the assignment gave
 136 >> you greater insight into some aspect of OS design?
 137
 138 >> Is there some particular fact or hint we should give students in
 139 >> future quarters to help them solve the problems?  Conversely, did you
 140 >> find any of our guidance to be misleading?
 141
 142 >> Do you have any suggestions for the TAs to more effectively assist
 143 >> students in future quarters?
 144
 145 >> Any other comments?