---- 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
================
projects / pintos-anon / blobdiff