+-------------------------+ | CS 439 | | PROJECT 4: FILE SYSTEMS | | DESIGN DOCUMENT | +-------------------------+ The questions in this design document should reflect the design of the code you wrote for the project. Your grade will reflect both the quality of your answer in this document and the quality of the design implementation in your code. You may receive partial credit for answering questions for parts of the project that you did not get to implement, but you must indicate in your answer that there is no corresponding implementation, or you will not receive any credit. For each question, you should include both the name of the file(s), function name(s), and the line numbers where the relevant code may be found. These design documents will be completed and submitted as a group. Please use this document as a guide for design and discuss the questions and their potential answers prior to beginning implementation. When you have completed your design document, submit it to the Canvas assignment Project 4 Design and Documentation. ***Your submission must be a text file and each line must not extend past 80 characters. In addition, your submission must contain all of the original material and not exceed 18,000 characters. The character count will be measured using the Linux command wc. (Note that rtf files are NOT text files.) ---- Team Information ---- >> Fill your names, UT EIDs, CS logins, email addresses, and unique numbers: Name: EID: CS login: Email: Unique Number: Name: EID: CS login: Email: Unique Number: Name: EID: CS login: Email: Unique Number: Name: EID: CS login: Email: Unique Number: Slip days used on this project: ---- PRELIMINARIES ---- >> If you have any preliminary comments on your submission or notes for the >> TAs, give them here. >> Please cite any offline or online sources you consulted while >> preparing your submission, other than the Pintos documentation, course >> text, lecture notes, and course staff. INDEXED AND EXTENSIBLE FILES ============================ ---- DATA STRUCTURES ---- >> A1: Copy here the declaration of each new or changed `struct' or >> `struct' member, global or static variable, `typedef', ‘#define’, or >> enumeration that was necessary for your indexed and extensible file >> implementation. Identify the purpose of each in 25 words or less. >> A2: What is the maximum size of a file supported by your inode >> structure? Show your work. ---- SYNCHRONIZATION ---- >> A3: Explain how your code avoids a race if two processes attempt to >> extend a file at the same time. >> A4: Suppose processes A and B both have file F open, both >> positioned at end-of-file. If A reads and B writes F at the same >> time, A may read all, part, or none of what B writes. However, A >> may not read data other than what B writes, e.g. if B writes >> nonzero data, A is not allowed to see all zeros. Explain how your >> code avoids this race. >> A5: Explain how your synchronization design provides "fairness". >> File access is "fair" if readers cannot indefinitely block writers >> or vice versa. That is, one or many processes reading from a file >> cannot forever prevent another process from writing to the file, and >> one or many processes writing to a file cannot forever prevent >> another process from reading the file. ---- RATIONALE ---- >> A6: Is your file layout a multilevel indexed structure? If so, why >> did you choose this particular combination of direct, indirect, and >> doubly indirect blocks? If not, why did you choose an alternative >> file structure, and what advantages and disadvantages does your >> structure have, compared to a multilevel index? >> In your explanation, include at least two reasons to support your >> choices. SUBDIRECTORIES ============== ---- DATA STRUCTURES ---- >> B1: Copy here the declaration of each new or changed `struct' or >> `struct' member, global or static variable, `typedef', ‘#define’, or >> enumeration that was necessary for your subdirectory >> implementation. Identify the purpose of each in 25 words or less. ---- ALGORITHMS ---- >> B2: Describe your code for traversing a user-specified path. How >> do traversals of absolute and relative paths differ? ---- SYNCHRONIZATION ---- >> B3: How do you prevent races on directory entries? For example, >> only one of two simultaneous attempts to remove a single file >> should succeed, as should only one of two simultaneous attempts to >> create a file with the same name, and so on. >> B4: Does your implementation allow a directory to be removed if it >> is open by a process or if it is in use as a process's current >> working directory? If so, what happens to that process's future >> file system operations? If that’s not allowed, how do you >> prevent it? ---- RATIONALE ---- >> B5: What type of variable/structure did you use to represent the >> current directory of a process? Why did you choose this >> representation? Give at least two reasons. SURVEY QUESTIONS ================ Answering these questions is optional, but it will help us improve the course in future quarters. Feel free to tell us anything you want--these questions are just to spur your thoughts. You may also choose to respond anonymously in the course evaluations at the end of the quarter. >> In your opinion, was this assignment, or any one of the three problems >> in it, too easy or too hard? Did it take too long or too little time? >> Did you find that working on a particular part of the assignment gave >> you greater insight into some aspect of OS design? >> Is there some particular fact or hint we should give students in >> future quarters to help them solve the problems? Conversely, did you >> find any of our guidance to be misleading? >> Do you have any suggestions for the TAs to more effectively assist >> students in future quarters? >> Any other comments?