Here some hints for lab 7. Actually, they're really about lab 5, which could have been better documented and shipped with a better test suite (in general, it's hard or impossible to provide a set of tests that proves an implementation correct, but in this case, there was room for improvement; sorry about that). Errors in lab 5 would affect the shell because the shell obviously needs to gain access to the file system. So here are a few things that should have been emphasized in lab 5:

• In funmap(), the use of the dirty parameter is as follows: if a page that is being unmapped has the PTE_D bit set and the dirty parameter = 1, then dirty the page by calling fsipc_dirty() with appropriate parameters. If the dirty parameter = 0, then the unmapping still has to happen but not the dirtying-via-the-calling-of-fsipc_dirty()
• A corollary of the above is that the dirty parameter matters: make sure when you call funmap() that you are supplying the right value for this parameter.
• In file_block_walk(), you may need to allocate an indirect block (to hold block pointers). This newly allocated block needs to be zeroed out (otherwise there would be bogus pointers).
• Some of you may have had errors in your read_block() and write_block() functions in fs/fs.c. Please read the specifications and lab instructions for those functions extremely carefully. For write_block, note that the PTE_USER constant appears but not as the actual value of the permission parameter. Also, write_block() should always write a block to disk (despite a stray comment in the lab5 instructions).
• file_map_block() should probably be calling file_block_walk(), but note that that call doesn't remove file_map_block()'s responsibility to allocate a block.
• If you're having trouble getting your shell to work and/or you think you have bugs in your file system, you may find it useful to debug using a much simpler program. We've included user/testwrite.c, but you can also write your own. In general, if you're getting errors that are hard to explain, it's best to try to write a very short program that reproduces the bug and then debug that shorter program.