This is not the same as taking a lock across a couple of
lines of code to check or set a variable in a race-free
- way, etc. That's fine.
+ way, etc. That's fine. The issue is waiting for I/O to
+ complete, not for updating little bits of metadata.
A4:
Many answers are implicitly predicated on the fact that Pintos
locks and semaphores have fair, first-come, first-served queuing.
- Most students don't mention it, though.
+ Most students don't mention it, though. Give a bonus point if
+ they do.
The typical answer depends on the answer to A4:
- High overhead for small files.
+ At least two reasons must be mentioned.
+
SUBDIRECTORIES
==============
working directory: I haven't seen any of these groups make
sensible claims yet.
+ At least two reasons must be given.
+
BUFFER CACHE
============
C1:
struct inode should drop inode_disk; if it doesn't, then take off
- points. This might have been mentioned in A1 instead.
+ points. Take off a lot of points if they This might have been mentioned in A1 instead.
Expect to see a cache entry structure containing the following
members:
--- /dev/null
+HW3 DESIGN SUMMARY
+==================
+
+OVERALL
+
+ DOCUMENTATION
+ -20 Egregious violation of style versus design document example
+ -10 Numerous excessively long lines (> 79 characters)
+ -10 Numerous capitalization, punctuation, spelling, or grammar errors
+
+ DESIGN
+ -10 Failure to check return value of malloc()
+ -10 Use of ASSERT to check something that can actually fail, e.g. malloc()
+
+ CODING STYLE
+ -10 Inconsistent or bad coding style: no indentation, cramming
+ many statements into one line, other issues at TA's discretion
+ -10 Numerous very long source code lines (> 100 characters)
+ -10 Commented-out or #if'd out code makes real code hard to read
+ -10 Many missing comments on structure, structure members,
+ global or static variables, or function definitions
+ -10 Function(s) should be decomposed for clarity [indicate function]
+ -10 Cut-and-pasted code should be made into function [indicate where]
+ -10 Uninformative or deceptive identifiers
+
+Subtotal: /10 (not capped)
+
+PROBLEM 1: INDEX AND EXTENSIBLE FILES
+
+ DOCUMENTATION
+ -30 Grossly inaccurate: documentation has no resemblance to code
+ -15 Important inaccuracies: documentation and code differ significantly
+ [indicate how]
+ -5 Minor inaccuracies: documentation and code differ [indicate how]
+ -5 A1: Missing entirely/missing comments or purpose/too long
+ -1 A1: "start" member retained in inode_disk but not used
+ -2 A1: "unused" array in inode_disk should be used for block pointers
+ -5 A2: Missing/non-responsive/too long/too short
+ -2 A2: Didn't show work or provide enough information to reproduce
+ -2 A2: Math doesn't add up
+ -3 A2: Incorrect claim to have 128 indirect or doubly indirect blocks
+ -5 A3: Missing/non-responsive/too long/too short
+ -5 A4: Missing/non-responsive/too long/too short
+ -5 A5: Missing/non-responsive/too long/too short
+ +1 A5: Mentioned that locks and semaphores are FIFO ordered.
+ -3 A5: Didn't describe one of two rules needed for fairness
+ -5 A5: Didn't describe either of two rules needed for fairness
+ -2 A5: Use of timer to ensure fairness
+ -2 A5: Claim that "rare" events do not affect fairness
+ -5 A6: Missing/non-responsive/too long/too short
+ -3 A6: Mentioned only one reason
+
+ DESIGN
+ -30 Not implemented
+ -5 Global lock for file extension
+ -5 Check on file length followed by obtaining lock fails to recheck length
+ -15 Reads or writes wait for one another, even when file not being extended
+
+Subtotal: /30 (capped at 0)
+
+PROBLEM 2: SUBDIRECTORIES
+
+ DOCUMENTATION
+ -30 Grossly inaccurate: documentation has no resemblance to code
+ -15 Important inaccuracies: documentation and code differ significantly
+ [indicate how]
+ -5 Minor inaccuracies: documentation and code differ [indicate how]
+ -5 B1: Missing entirely/missing comments or purpose/too long
+ -1 B1: Not mentioned how files and directories are distinguished
+ -2 B1: Global list of open directories lacks lock
+ -2 B1: Global list of directories has no way to wait for directory access
+ -5 B2: Missing/non-responsive/too long/too short
+ -5 B3: Missing/non-responsive/too long/too short
+ -5 B4: Missing/non-responsive/too long/too short
+ -5 B5: Missing/non-responsive/too long/too short
+ -3 B5: Claim that extra code is needed to avoid deleting parents of cwds
+ -5 B6: Missing/non-responsive/too long/too short
+ -3 B6: Mentioned only one reason
+
+ DESIGN
+ -30 Not implemented
+ -10 Use of string for current directory is slow, takes a lot of
+ memory, and has undesirable semantics for directory removed
+ and re-created
+ -5 Use of sector number for current directory has bad semantics
+ when a directory's inode is reused later
+ -10 Operations on different directories must wait for one another
+
+Subtotal: /30 (capped at 0)
+
+PROBLEM 3: BUFFER CACHE
+
+ DOCUMENTATION
+ -30 Grossly inaccurate: documentation has no resemblance to code
+ -15 Important inaccuracies: documentation and code differ significantly
+ [indicate how]
+ -5 Minor inaccuracies: documentation and code differ [indicate how]
+ -5 C1: Missing entirely/missing comments or purpose/too long
+ -2 C1: Didn't drop inode_disk from struct inode
+ -5 C2: Missing/non-responsive/too long/too short
+ -5 C3: Missing/non-responsive/too long/too short
+ -5 C4: Missing/non-responsive/too long/too short
+ -5 C5: Missing/non-responsive/too long/too short
+ -5 C6: Missing/non-responsive/too long/too short
+ -2 C6: Omitted one of three workloads
+ -4 C6: Omitted two of three workloads
+
+ DESIGN
+ -30 Not implemented
+ -3 Modifies all cache entries on block access or eviction
+ -10 Metadata are preferred over data to the extent that the cache
+ will contain only metadata in many cases
+ -5 Busy waits in read-ahead
+ -5 Creates new thread on most reads or on every read
+ -5 In some cases operations on cached blocks may have to wait for
+ I/O of unrelated blocks to complete
+
+Subtotal: /30 (capped at 0)