Design Project One: Frequently-Asked Questions

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 closed?

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 so..."

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 medium-size files?

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.