Lab 1: Filesystems and System Calls
This handout was adapted from Jerry Cain’s Spring 2018 offering.
The first and last exercises are problem set-esque questions that could easily appear on a midterm or final exam. In fact, all of the questions asked under Problem 3 were on previous midterms and finals. The middle problem is an experiment that’ll require you fire up your laptop and play with some programs.
I’ve created a Slack channel for Lab 1 discussion (aptly named #lab1), and all students (but particularly remote students) are encouraged to share their ideas there.
Problem 1: Direct, Singly Indirect, and Doubly Indirect Block Numbers
Assume blocks are 512 bytes in size, block numbers are four-byte ints,
and that inodes include space for 6 block numbers. The first three contain
direct block numbers, the next two contain singly indirect block numbers, and
the final one contains a doubly indirect block number. (Note: This is
different from the scheme we’ve discussed in class.)
- What’s the maximum file size?
- How large does a file need to be before the relevant inode requires the first singly indirect block number be used?
- How large does a file need to be before the relevant inode requires the first doubly indirect block number be used?
- Draw as detailed an inode as you can if it’s to represent a regular file that’s 2049 bytes in size.
Problem 2: Experimenting with the stat utility
This problem is more about exploration and experimentation, and not so much about generating a correct answer. The file system reachable from each myth machine consists of the local file system (restated, it’s mounted on the physical machine) and networked drives that are grafted onto the fringe of the local file system so that all of AFS – which consists of many, many independent file systems from around the globe – all contribute to one virtual file system reachable from your local / directory.
Log into myth53 and use the stat command line utility (which is a user
program that makes calls to the stat system call as part of its execution)
and prints out oodles of information about a file. Type in the following
commands and analyze the output:
stat /stat /tmpstat /usrstat /usr/binstat /usr/bin/g++stat /usr/bin/g++-5
The output for each of the five commands above all produce the same device ID
but different inode numbers. Read through
this
to gain insight on what the Device values are.
For each of the above commands, replace stat with stat -f to get
information about the file system on which the file resides (block size, inode
table size, number of free blocks, number of free inodes, etc).
Now log into myth54 and run the same commands. Why are the outputs of stat
and stat -f the same in some cases and different in others?
Now analyze the output of the stat utility when levied against AFS mounts
where the master copies of all /usr/class and /usr/class/cs110 files
reside. Do this from both myth53 and myth54.
stat /usr/classstat -f /usr/classstat /afs/ir.stanford.edu/classstat -f /afs/ir.stanford.edu/classstat /usr/class/cs110stat /afs/ir.stanford.edu/class/cs110stat -f /usr/class/cs110
Why are most of the outputs the same for myth53 compared to myth54? Which
ones are symbolic links? Why are the device numbers for remotely hosted file
systems so small? What about these commands?
stat /afs/northstar.dartmouth.edustat -f /afs/northstar.dartmouth.edustat /afs/asu.edustat -f /afs/asu.edu
What files can you see within the dartmouth.edu and asu.edu mounts?
Problem 3: Short Answer Questions
Provide clear answers and/or illustrations for each of the short answer questions below. Each of these questions is either drawn from old exams or based on old exam questions. Questions like this will certainly appear on your own midterm.
- The
dupsystem call accepts a valid file descriptor, claims a new, previously unused file descriptor, configures that new descriptor to alias the same file session as the incoming one, and then returns it. Briefly outline what happens to the relevant file entry table and vnode table entries as a result ofdupbeing called. (Readman dupif you’d like, though don’t worry about error scenarios). - Now consider the prototype for the
linksystem call (peruseman link). A successful call tolinkupdates the file system so the file identified byoldpathis also identified bynewpath. Oncelinkreturns, it’s impossible to tell which name was created first. (To be clear,newpathisn’t just a symbolic link, since it could eventually be the only name for the file.) In the context of the file system discussed in lecture and/or the file system discussed in Section 2.5 of the secondary textbook, explain how link might be implemented. - Explain what happens when you type
cd .././../.at the shell prompt. Frame your explanation in terms of our discussion of directories in lecture, and the fact that the inode number of the current working directory is the only relevant global variable maintained by your shell. - All modern file systems allow symbolic links to exist as shortcuts for
longer absolute and relative paths (e.g.
sanitycheckmight be a symbolic link for/afs/.ir/users/r/e/rebs/cs110/assign1/tools/sanitycheck, andtests.txtmight be a symbolic link for./mytests/tests.txt. Explain how your the absolute pathname resolution process we discussed in lecture would need to change to resolve absolute pathnames to inode numbers when some of the pathname components might be symbolic links.