If you get everything working and throughly tested early, you might
consider adding extra-credit features.
Some suggestions include
- Maintain in memory a cache of available inodes, to avoid searching the
on-disk ilist when allocating a new inode.
- If a client read request is (or contains) a whole block,
read the data directly from the disk to the client's buffer, rather
than copying.
Similarly for write.
- Add a pool of in-memory copies of disk blocks called a disk cache.
The pool should be managed LRU--i.e., whenever a disk block is needed that
is not already in memory, the least-recently used block in the cache
is used to hold it.
Writes only update the copy of a disk block that is in memory.
When the buffer is replaced by another block, it is written out if it is
dirty.
Dirty blocks are also written out at shutdown.
Real file systems relay on a disk cache for performance.
I cannot stress too strongly, however, that you should not even think
of adding these features until the required part of the project is
completely written and debugged.
In fact, one point of including this list is to stress that these features
are not part of the required project.