Design Project One:
Last updated: $Date: 2006/03/21 00:50:35 $
Q: Do I really need to stay within 2,500 words?
A: Yes. In fact, you must print the word count at the end
of your final report.
Q: The design project assignment says that the interface to our
file system consists of standard Unix file system calls read(),
write(), open(), and unlink(). Does this mean files are never
A: This was a bug in the assignment; close() should also be part
of the interface.
Q: Must my design support modifications to files?
A: No. You can assume that once a file has been closed for writing
(i.e., once the Web Server has called close()), the Web Server cannot
make more changes to it. It's possible the Web Server will later ask
to delete the entire file, but not to modify the existing content or
append to it.
Q: I see that the design proposal says my file system can be hosed
after a machine crash, but what do you mean by "In the absence of
such crashes, however, the file system should allow clients to
retrieve previously stored files that are still resident." ? To ask
my question another way, to what extent does my design need to
handle clean shutdowns?
A: Clean shutdowns can happen. You can't lose data when a shutdown
happens, but these shutdowns are a special case. Specifically, if
the operator of the computer performs a clean shutdown of the
computer running your file system, then your file system would
receive a special shutdown signal. This signal allows your file
system to take any appropriate steps in response to a shutdown; what
those "steps" are will depend on the particulars of your design.
Q: Isn't asking us to support 1 byte files mutually exclusive with
requiring a minimum of 75% disk utilization? For example, in the case
where all files are 1 byte long, even storing a single byte of
metadata per file violates this requirement.
A: It's fine to not handle that case well. No file system will ever
get 75% disk use when filled with 1 byte (or even 1K) files. The 75%
constraint is meant to apply to large files (e.g. don't tie up 10M of
disk for a 1M file), and meta-data (e.g. don't keep a log of all the
files on disk which itself fills half the disk). You should mention
that one of your assumptions is that you aren't going to handle that
case well because it is unlikely for your target application.
Q: For my design, I'd like to use some ideas from the Unix File System
(UFS), or some other file system. Is it OK to do so?
A: It's fine to be similar to another file system, but you should
still describe the design concepts you borrow. For example, don't just
say "I keep an i-list like Unix". Rather, re-describe how your i-list
works, which will happen to be similar to Unix. Also, be sure to cite
the source of your ideas. For example, you could say "Like UFS, my
system keeps an i-list which catalogues all the files on disk like
Q: The assigment says that "You can anticipate a range of file sizes
from small (e.g., a file with temperature readings) to large (e.g., a
file containing a video clip)." Does this mean that there are no
A: No. The three sample workloads we specify involve only small and
large-sized files, but your file system should be able to handle files
of any reasonable size.
Q: Can our filesystem use the entire 120 MB of system RAM?
A: That seems difficult to justify. The user wants to do
something with that RAM (like run the Web server), not have the
operating system gobble it all up. Probably 20 MB would be a more
reasonable RAM utilization; 60 MB is really pushing the limits. But
the important part isn't really how much RAM you use -- it's that you
know how much RAM you will use, and can demonstrate your figure with a
persuasive analysis. (The amount might even be different across the
assigned workloads, or in the average case vs. worst case.)
Is it reasonable to assume that the OS, web server, and so on are on a
different disk from our filesystem?
No, the machine only has one hard disk. But the operating system and
other executable (like the Web server) are just files themselves --
files that your filesystem will store like anything else. So this
should not be a problem.