X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=doc%2Ffilesys.tmpl;h=f3bd101d67f26c2d8c894ef45d5afdc68609f59c;hb=919347c164606c3f1544b2e8bd62f505aeda80a1;hp=63329abea80c7131684b372518e7d2e67b30a489;hpb=bfc9e18a6723b2315ef521282a8b42119338ece9;p=pintos-anon diff --git a/doc/filesys.tmpl b/doc/filesys.tmpl index 63329ab..f3bd101 100644 --- a/doc/filesys.tmpl +++ b/doc/filesys.tmpl @@ -1,8 +1,8 @@ - +-------------------------+ - | CS 140 | - | PROJECT 4: FILE SYSTEMS | - | DESIGN DOCUMENT | - +-------------------------+ + +-------------------------+ + | CS 140 | + | PROJECT 4: FILE SYSTEMS | + | DESIGN DOCUMENT | + +-------------------------+ ---- GROUP ---- @@ -19,112 +19,112 @@ FirstName LastName >> Please cite any offline or online sources you consulted while >> preparing your submission, other than the Pintos documentation, course ->> text, and lecture notes. +>> text, lecture notes, and course staff. - INDEXED AND EXTENSIBLE FILES - ============================ + INDEXED AND EXTENSIBLE FILES + ============================ ---- DATA STRUCTURES ---- ->> Copy here the declaration of each new or changed `struct' or `struct' ->> member, global or static variable, `typedef', or enumeration. ->> Identify the purpose of each in 25 words or less. +>> A1: Copy here the declaration of each new or changed `struct' or +>> `struct' member, global or static variable, `typedef', or +>> enumeration. Identify the purpose of each in 25 words or less. ->> What is the maximum size of a file supported by your inode structure? +>> A2: What is the maximum size of a file supported by your inode +>> structure? Show your work. ---- SYNCHRONIZATION ---- ->> Explain how your code avoids a race if two processes attempt to extend ->> a file at the same time. +>> A3: Explain how your code avoids a race if two processes attempt to +>> extend a file at the same time. ->> Suppose processes A and B both have file F open, both positioned at ->> end-of-file. If A reads and B writes F at the same time, A may read ->> all, part, or none of what B writes. However, A may not read data ->> other than what B writes, e.g. if B writes nonzero data, A is not ->> allowed to see all zeros. Explain how your code avoids this race. +>> A4: Suppose processes A and B both have file F open, both +>> positioned at end-of-file. If A reads and B writes F at the same +>> time, A may read all, part, or none of what B writes. However, A +>> may not read data other than what B writes, e.g. if B writes +>> nonzero data, A is not allowed to see all zeros. Explain how your +>> code avoids this race. ->> Explain how your synchronization design provides "fairness". File ->> access is "fair" if readers cannot indefinitely block writers or vice ->> versa. That is, many processes reading from a file cannot prevent ->> forever another process from writing the file, and many processes ->> writing to a file cannot prevent another process forever from reading ->> the file. +>> A5: Explain how your synchronization design provides "fairness". +>> File access is "fair" if readers cannot indefinitely block writers +>> or vice versa. That is, many processes reading from a file cannot +>> prevent forever another process from writing the file, and many +>> processes writing to a file cannot prevent another process forever +>> from reading the file. ---- RATIONALE ---- ->> Is your inode structure a multilevel index? If so, why did you choose ->> this particular combination of direct, indirect, and doubly indirect ->> blocks? If not, why did you choose an alternative inode structure, ->> and what advantages and disadvantages does your structure have, ->> compared to a multilevel index? +>> A6: Is your inode structure a multilevel index? If so, why did you +>> choose this particular combination of direct, indirect, and doubly +>> indirect blocks? If not, why did you choose an alternative inode +>> structure, and what advantages and disadvantages does your +>> structure have, compared to a multilevel index? - SUBDIRECTORIES - ============== + SUBDIRECTORIES + ============== ---- DATA STRUCTURES ---- ->> Copy here the declaration of each new or changed `struct' or `struct' ->> member, global or static variable, `typedef', or enumeration. ->> Identify the purpose of each in 25 words or less. +>> B1: Copy here the declaration of each new or changed `struct' or +>> `struct' member, global or static variable, `typedef', or +>> enumeration. Identify the purpose of each in 25 words or less. ---- ALGORITHMS ---- ->> Describe your code for traversing a user-specified path. How do ->> traversals of absolute and relative paths differ? - ->> Look over "pwd.c" in src/examples. Briefly explain how it ->> determines the present working directory. +>> B2: Describe your code for traversing a user-specified path. How +>> do traversals of absolute and relative paths differ? ---- SYNCHRONIZATION ---- ->> How do you prevent races on directory entries? For example, only one ->> of two simultaneous attempts to remove a single file should succeed, ->> as should only one of two simultaneous attempts to create a file with ->> the same name, and so on. +>> B4: How do you prevent races on directory entries? For example, +>> only one of two simultaneous attempts to remove a single file +>> should succeed, as should only one of two simultaneous attempts to +>> create a file with the same name, and so on. ->> Does your implementation allow a directory to be removed if it is in ->> use as a process's current directory? If so, what happens to that ->> process's future file system operations? If not, how do you prevent ->> it? +>> B5: Does your implementation allow a directory to be removed if it +>> is open by a process or if it is in use as a process's current +>> working directory? If so, what happens to that process's future +>> file system operations? If not, how do you prevent it? ---- RATIONALE ---- ->> Explain why you chose to represent the current directory of a process ->> the way you did. +>> B6: Explain why you chose to represent the current directory of a +>> process the way you did. - BUFFER CACHE - ============ + BUFFER CACHE + ============ ---- DATA STRUCTURES ---- ->> Copy here the declaration of each new or changed `struct' or `struct' ->> member, global or static variable, `typedef', or enumeration. ->> Identify the purpose of each in 25 words or less. +>> C1: Copy here the declaration of each new or changed `struct' or +>> `struct' member, global or static variable, `typedef', or +>> enumeration. Identify the purpose of each in 25 words or less. ---- ALGORITHMS ---- ->> Describe how your cache replacement algorithm chooses a cache block to ->> evict. +>> C2: Describe how your cache replacement algorithm chooses a cache +>> block to evict. ->> Describe your implementation of write-behind. +>> C3: Describe your implementation of write-behind. ->> Describe your implementation of read-ahead. +>> C4: Describe your implementation of read-ahead. ---- SYNCHRONIZATION ---- ->> When one process is actively reading or writing data in a buffer cache ->> block, how are other processes prevented from evicting that block? +>> C5: When one process is actively reading or writing data in a +>> buffer cache block, how are other processes prevented from evicting +>> that block? ->> During the eviction of a block from the cache, how are other processes ->> prevented from attempting to access the block? +>> C6: During the eviction of a block from the cache, how are other +>> processes prevented from attempting to access the block? ---- RATIONALE ---- ->> Describe a file workload likely to benefit from buffer caching, and ->> workloads likely to benefit from read-ahead and write-behind. +>> C7: Describe a file workload likely to benefit from buffer caching, +>> and workloads likely to benefit from read-ahead and write-behind. - SURVEY QUESTIONS - ================ + SURVEY QUESTIONS + ================ Answering these questions is optional, but it will help us improve the course in future quarters. Feel free to tell us anything you