![]() |
|
The project for the current term is to implement (on a simulated disk) a file system based on the design explored in the lectures. This project is divided into four pieces, one piece at a time due every other week or so during the 10-weeks of the term. You must read and follow the Project Expectations. Study the grading sheet given below.
This is Part 0 of the project for this term. You are expected to
study and modify the source code files given in P0.tbz
and achieve the functionality described below. Do not use source
code files of others or even those of mine but from prior
terms.
The tar ball P0.tbz is a collection of files given so
that (i) you can get started quickly with our project, and (ii) you
can see the style of how larger systems programs are
written. Download P0.tbz from the link above. In
the OSIS Lab, it can be un-tar-ed as follows:
tar xvvfj
P0*.tbz
Be Considerate. Do make sure that you are not using up too
much space (say > 10 MB) in your home directory. The
following will show your disk space usage: du -s
~
Coming into the course, you are expected to be comfortable with
Unix commands. Try all the commands of
the Minimal List of Unix
Commands You cannot claim to be Unix-familiar unless you
have used them all a few times. Use script (read man
script) to demonstrate that you invoked the
commands. A few commands cannot be run unless you are super
user; for such commands, just capture its message. Turn this file in
as a file named (exactly) cmdsTried.txt.
Coming into the course, you are expected to be comfortable
with gdb.
Debugging large programs requires the construction of (extra) observer
methods. Using gdb or some other debugger is not as
effective as invoking observers and studying their output in a
peaceful place ("under a tree"). Nevertheless, gdb can be useful as a
last resort, and you must be able to use it well.
script. Untar P0.tbz. Make P0 as given. Run
our program P0 through gdb.setArgsGiven(buf,
arg, types, nArgsMax); SimDisk
constructor.doMakeFV.buf, arg, types, nArgsMax of
setArgsGiven.
gdbSession.txtBy the time P0 is due, we would have covered the essentials of our
File Sys project. The functionality of P0.tbz
is described below. Additional details of the code are/were explained
in the lectures and in ReadMeP0.txt included in the
tar-ball.
fs33% mkfs disknm.dsk creates an initially empty file volume on the simulated disk
named disknm.dsk. The file volume so
constructed is the current file volume as used
below. If disknm.dsk is not already
created, it will now.
The maxfnm, the number of i-nodes, and the i-node
height are all given in the diskparams.dat file
corresponding to the line for disknm.dsk. The
names of 433-files are at most maxfnm characters
long. Valid characters in file names are a-z, A-Z, 0-9,
hyphen (minus), and period ('.'); all other characters (spaces,
slashes, control characters, etc.) are illegal. The
height does include the fileSize field.
Here is an example diskparams.dat. Lines starting
with # are comments. For clarity, I have lined-up
the columns, but the actual diskparams.dat may not
do so.
# diskName nBlocks nBytesPerSector maxFnm nInodes iNodeHt D1 128 512 8 20 3 D2 1024 256 16 100 8
fs33% cp @P0/test0.cpp myfile.txt copies P0/test0.cpp from your Linux (indicated
by the @ sign) current working directory to the current (for now,
root) directory of the file volume, as a file
named myfile.txt and prints to stdout
the i-node number of myfile.txt.
If myfile.txt already exists, the new content
silently replaces it. In the cp commands, we
need to simultaneously deal with path names of files in
433-file-volume and Linux. Only in such cases, the
latter are prefixed with the @ symbol.
fs33% cp myfile.txt @P0/test1.cpp
copies myfile.txt of the current file volume
to P0/test1.cpp of your Linux current
directory and prints to stdout the i-node number
of myfile.txt. If
P0/test1.cpp already exists, it is silently
replaced.
fs33% cp myfile.txt file2.txtcopies myfile.txt of the current file volume
to file2.txt of the current volume and prints
to stdout the i-node number
of file2.txt.
If file2.txt already exists, the new content
replaces it.
fs33% lsprints a listing, much like the Unix ls -lisa,
of all the files in the root directory of the
current file volume.
fs33% rm myfile.txtremove the file named myfile.txt from the root
directory and prints to stdout the i-node number
that myfile.txt had. If the
file named myfile.txt does not exist, be quiet and
print 0.
prints the contents of i-node numbered 4, if it exists, of the current file volume.
In the P0.tbz, there is a stdTestScriptP0.txt.
Use it as in ./P0 < stdTestScriptP0.txt.
Part of large program development is independently, but wisely,
deciding what to do for certain "erroneous" situations. Should we ask
the professor for what to do for every possible error you can think
of? [Answer: No. You think about it. You take a reasonable
action. You document this in your source code, and in
ReadMe.txt. And, be ready to defend your choice should it
be questioned.] Should SimDisk() constructor
printf or cout>> an error message? [No.]
How should it deal with parameters so wrong that it cannot construct a
simulated disk? [Think.] Remember that one of the goals of CEG
433/633 is to make you think about larger programs. Part of this is to
supply missing, but needed, details in the problem description.
Study the source code of P0 so thoroughly that you could have
written it. Then, answer the itemized questions below in a file
named answers.txt.
fopen, fclose, fread, fwrite, fstat, fscanf, fprintf,
printf, sprintfsimDisk.cpp, what is the point in
verifying that statBuf.st_size == nSectorsPerDisk *
nBytesPerSector?
uint
FileVolume::read33file(byte *fs33leaf, byte
*unixFilePath)uint FileVolume::write33file(byte *unixFilePath, byte
*fs33leaf)You will find that P0, as given, is "functional" but fragile (not
robust). Improve it so that it is crash-proof no matter what inputs
are given. Describe the changes you made in a file
named improvements.txt. In later project phases, we (you
and I) will replace invocations of TODO by working
code.
Only the additional elements compared to the given P0 are
described below. Add these appropriately to the test
script. Our path name syntax is the same as Unix path
names. Obviously, not every arbitrary string is a valid
path or name. Also, the dot and the dot-dot are not permissible
as arguments in some contexts below. Nevertheless these commands
must be robust.
da is either a normal file or a directory. (i)
If da does not exist, return 0 and nothing is altered
in the file volume. (ii) If db does not exist in the
current directory, da is renamed as db.
(iii) If db is an existing but ordinary file, delete
it and then do as in (ii). For (ii) and (iii) return the i-number
of db.
Recall that Unix command mv does two things: (a)
when the last argument given is a directory already existing, it
moves the files or directories given in the rest of the
arguments from where they are into this target directory, or (b)
renames the first argument file or directory into the second
argument. Look up the man page for more details. Implement
(b). Recall that in this P0 we have just the root directory and
no subdirectories.
myfile.txt located in the current directory of
the current volume and then invokes the
original inode command.In this course, the focus is on OS usage and design -- not on OOP
and not on bug-free software engineering. We try to give you credit
for your programs even when they are buggy as long as the ideas behind
their construction are solid and your program can successfully
navigate your own testscript.txt.
The P0 as given has (just) one bug. After removing a file, if we
try to do a cp, it fails. (Of course, the cp is given valid
arguments). A second attempt succeeds. You will receive 25
"bonus" points if you can pinpoint what causes this problem
and provide a fix in the file named bugfix.txt. If you
discover additional bugs (we hope not!), describe them also to receive
an additional 25 bonus points for all the descriptions.
All submissions are done using the turnin program located in /home/ceg433/ceg43300/bin on all the Linux machines in the OSIS Lab. Its first argument is the name of the part of the project, which is uppercase P followed by one digit, e.g., P0. Following this are the names of files that you intend to submit. So, for this part, the command line looks like this:
/home/ceg433/ceg43300/bin/turnin P0 names-of-files-you-wish-to-submit
![]() |
|
|||
| Extra credit points are awarded in recognition of good work and extra work, in addition to the max possible points. Quality is subjectively judged. Merely turning in a file will not receive full score. Some items have a cascading effect. | ||||
| Student | OSIS Login ID | Extra credit | Points |
| Item description | Max | Points |
ReadMe.txt exists with content as described in Project Expectations |
10 | - |
Your testscript.txt is designed so that all the functionality
is demonstrated, including robustness. |
10 | - |
Your program successfully navigates your own testscript.txt.
( If yours is too simple, we may run it through our script that you
will get to see only after the due date.) |
10 | - |
cmdsTried.txt shows use of at least 10 of
Minimal List of Unix Commands |
10 | - |
answers.txt |
10 | - |
gdbSession.txt |
10 | - |
| Improvement | 10 | - |
mv da db (db
does not exist) |
10 | - |
mv da db (db does
exist) |
10 | - |
inode printing for both i-numbers and
file names |
10 | - |
Fixing the rm bug described above in bugfix.txt |
B25 | - |
| Discovering additional bugs | B25 | - |
| Late submission: minus 2% per day late; Not accepted at all after 4 days | -8 | - |
Files were not submitted using turnin program = minus 10
points |
-10 | - |
| Total | 100 | - |
| - |
| Copyright © 2009 pmateti@wright.edu |