X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=doc%2Ffilesys.tmpl;h=e3d6f56808328074359a14b94b4d2991a004d090;hb=refs%2Fheads%2Fsum0506;hp=63329abea80c7131684b372518e7d2e67b30a489;hpb=bb2ad624fa17035477be68c1f6b89710f2124b7a;p=pintos-anon diff --git a/doc/filesys.tmpl b/doc/filesys.tmpl index 63329ab..e3d6f56 100644 --- a/doc/filesys.tmpl +++ b/doc/filesys.tmpl @@ -26,102 +26,105 @@ FirstName LastName ---- 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? ---- 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 ============== ---- 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? +>> B2: 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 +>> B3: Look over "pwd.c" in src/examples. Briefly explain how it >> determines the present working directory. ---- 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 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? ---- 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 ============ ---- 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 ================