-@item SYS_lsdir
-@itemx void lsdir (void)
-Prints a list of files in the current directory to @code{stdout}, one
-per line, in no particular order.
-@end table
-
-We have provided @command{ls} and @command{mkdir} user programs, which
-are straightforward once the above syscalls are implemented. In Unix,
-these are programs rather than built-in shell commands, but
-@command{cd} is a shell command. (Why?)
-
-The @code{pintos} @option{put} and @option{get} commands should now
-accept full path names, assuming that the directories used in the
-paths have already been created. This should not require any extra
-effort on your part.
-
-@node Problem 4-4 Buffer Cache
-@section Problem 4-4: Buffer Cache
-
-Modify the file system to keep a cache of file blocks. When a request
-is made to read or write a block, check to see if it is stored in the
-cache, and if so, fetch it immediately from the cache without going to
-disk. (Otherwise, fetch the block from disk into cache, evicting an
-older entry if necessary.) You are limited to a cache no greater than
-64 sectors in size. Be sure to choose an intelligent cache
-replacement algorithm. Experiment to see what combination of accessed,
-dirty, and other information results in the best performance, as
-measured by the number of disk accesses. (For example, metadata is
-generally more valuable to cache than data.) Document your
-replacement algorithm in your design document.
-
-The provided file system code uses a ``bounce buffer'' in @struct{file}
-to translate the disk's sector-by-sector interface into the system call
-interface's byte-by-byte interface. It needs per-file buffers because,
-without them, there's no other good place to put sector
-data.@footnote{The stack is not a good place because large objects
-should not be allocated on the stack. A 512-byte sector is pushing the
-limit there.} As part of implementing the buffer cache, you should get
-rid of these bounce buffers. Instead, copy data into and out of sectors
-in the buffer cache directly. You will probably need some
-synchronization to prevent sectors from being evicted from the cache
-while you are using them.
-
-In addition to the basic file caching scheme, your implementation
-should also include the following enhancements:
-
-@table @b
-@item write-behind:
-Instead of always immediately writing modified data to disk, dirty
-blocks can be kept in the cache and written out sometime later. Your
-buffer cache should write behind whenever a block is evicted from the
-cache.
-
-@item read-ahead:
-Your buffer cache should automatically fetch the next block of a file
-into the cache when one block of a file is read, in case that block is
-about to be read.
-@end table
-
-For each of these three optimizations, design a file I/O workload that
-is likely to benefit from the enhancement, explain why you expect it
-to perform better than on the original file system implementation, and
-demonstrate the performance improvement.
-
-Note that write-behind makes your filesystem more fragile in the face
-of crashes. Therefore, you should
-periodically write all cached blocks to disk. If you have
-@func{timer_sleep} from the first project working, this is an
-excellent application for it. (If you're still using the base
-implementation of @func{timer_sleep}, be aware that it busy-waits, which
-is not an acceptable solution.) If @func{timer_sleep}'s delays seem too
-short or too long, reread the explanation of the @option{-r} option to
-@command{pintos} (@pxref{Debugging versus Testing}).
-
-Likewise, read-ahead is only really useful when done asynchronously.
-That is, if a process wants disk block 1 from the file, it needs to
-block until disk block 1 is read in, but once that read is complete,
-control should return to the process immediately while the read
-request for disk block 2 is handled asynchronously. In other words,
-the process will block to wait for disk block 1, but should not block
-waiting for disk block 2.
-
-When you're implementing this, please make sure you have a scheme for
-making any read-ahead and write-behind threads halt when Pintos is
-``done'' (when the user program has completed, etc), so that Pintos
-will halt normally and the disk contents will be consistent.
-
-@node File System Design Document Requirements
-@section Design Document Requirements
-
-As always, submit a design document file summarizing your design. Be
-sure to cover the following points:
-
-@itemize @bullet
-@item
-How did you choose to synchronize file system operations?