chore: minor grammar and formatting changes

mini-lsm/src/test_your_understanding/Week1/Day1.md

@@ -16,14 +16,13 @@
   - The order to store and probe memtables is directly related to the correctness of the storage engine itself. Memtables earlier in order represent more recent mutations of the client data. If we didn't maintain an order, we'd be returning incorrect values of data when asked by a client.
 
 - Is the memory layout of the memtable efficient / does it have good data locality? (Think of how Byte is implemented and stored in the skiplist...) What are the possible optimizations to make the memtable more efficient?
-  - Skip lists' nodes are scattered so the memory layout is not cache friendly. We could do key prefix compression to save memory 
-  but I dont know how to yet :-)
+  - Skip lists' nodes are scattered so the memory layout is not cache friendly. We could do key prefix compression to save memory.
 
 - So we are using parking_lot locks in this tutorial. Is its read-write lock a fair lock? What might happen to the readers trying to acquire the lock if there is one writer waiting for existing readers to stop?
-  - Not fair. Writer can starve; need to introduce fairness.
+  - Not fair. Writer can starve; we need to introduce explicit fairness if needed.
 
 - After freezing the memtable, is it possible that some threads still hold the old LSM state and wrote into these immutable memtables? How does your solution prevent it from happening?
-  - `state` lock should prevent this because we are taking a write lock while freezing which does the atomic swap of memtables. Need validation.
+  - `state` lock will prevent this because we are taking a write lock while freezing which does the atomic swap of memtables.
 
 - There are several places that you might first acquire a read lock on state, then drop it and acquire a write lock (these two operations might be in different functions but they happened sequentially due to one function calls the other). How does it differ from directly upgrading the read lock to a write lock? Is it necessary to upgrade instead of acquiring and dropping and what is the cost of doing the upgrade?
-  - I think dropping allows other operations to go through but not sure.
+  - Acquiring and releasing increases the responsiveness of the engine as other threads can continue making progress. 

mini-lsm/src/test_your_understanding/Week1/Day2.md

@@ -31,4 +31,5 @@
   The starter code provides the merge iter
 
 - If we want to get rid of self-referential structure and have a lifetime on the memtable iterator (i.e., MemtableIterator<'a>, where 'a =        memtable or LsmStorageInner lifetime), is it still possible to implement the scan functionality?
-  What happens if (1) we create an iterator on the skiplist memtable (2) someone inserts new keys into the memtable (3) will the iterator see the new key?
+  What happens if (1) we create an iterator on the skiplist memtable (2) someone inserts new keys into the memtable (3) will the iterator see the new key?
+  - <Unanswered>

mini-lsm/src/test_your_understanding/Week1/Day3.md

@@ -35,4 +35,5 @@
 
 #### Rust-specific
 
-- So Block is simply a vector of raw data and a vector of offsets. Can we change them to Byte and Arc<[u16]>, and change all the iterator interfaces to return Byte instead of &[u8]? (Assume that we use Byte::slice to return a slice of the block without copying.) What are the pros/cons?
+- So Block is simply a vector of raw data and a vector of offsets. Can we change them to Byte and Arc<[u16]>, and change all the iterator interfaces to return Byte instead of &[u8]? (Assume that we use Byte::slice to return a slice of the block without copying.) What are the pros/cons?
+  - <Unanswered>