COMS W4118 Spring 2008: Homework Assignment 6
Last Updated Apr 27th 2008
Due Thursday, May 8th at 11:59 PM
This homework consists of two components: a required written
assignment
and
an optional
programming
assignment for extra
credit.
Each is to be submitted via Courseworks.
The written components of the assignment is to be done alone, not in
teams. Discussion is encouraged but collaboration is not allowed.
The programming assignment is to be done in assigned
groups. If you are unsure about your group contact the
professor.
Written Assignment
Exercise numbers refer to the course textbook, Operating System
Concepts with Java. Each problem is worth 5 points.
- Are the open and close system calls strictly
necessary? How would a system work without them?
- Exercise 10.8.
- What are the advantages of hard links over soft links, and vice
versa?
- Exercise 11.6.
- How many disk accesses would be incurred in UNIX by opening the
file /usr/local/bin/emacs?
Assume that only the i-node for the root directory is cached, and that
all directories fit in one disk block.
- Exercise 12.2.
- Contrast RAID levels 0 through 5 in terms of read performance,
write performance, reliability, and space overhead.
- Assume a UNIX-like file system with 1 KB blocks and 32-bit disk
addresses. If an i-node contains 10 direct entries, and one
single, double, and triple indirect entry, what is the maximum file
size of the system?
- Exercise 13.3.
- Exercise 13.6.
You should submit your assignment via Courseworks->Class
Files->Shared Files->HW6_Written_Assignment. Upload your
answers in a single
ASCII text file. PDF and/or word documents are not accepted. The filename
should be
HW6.<uni>.txt For example, if your uni is sa3152, your
submission filename should be HW6.sa3152.txt
Programming Assignment: File Systems
Programming problems are to be done in your assigned
groups using one
of the VMs that has been
assigned to your group members. For all programming problems you will
be required to submit source code, a README file documenting
your files and code, and a test run of your programs. In addition, you
should submit a cover sheet using either homework_work.txt
or homework_nonwork.txt,
depending on whether or
not the programming assignment is completely working or not. For source
code
submissions, you only need to submit new source code files that you
created and kernel source code files that you changed. You should
clearly indicate your names, email addresses, and assigned group
number on your submission. Each group is required to submit one
writeup for the programming assignment.
You will build your own Linux kernel for this class. For each
homework assignment, you will build a new Linux kernel. The image
of the kernel you build for this assignment should be vmlinuz.hmwk6.
Grading for this assignment will be done based on
vmlinuz.hmwk6.
Description
This assignment is to add functionality to the linux kernel file system.
Purpose
- To improve understanding of how file system implementation in
practice.
Before you start
Make sure you have your VMs available and your MRL account It is
highly recommended that you study the file systems chapter in ULK.
Programming Assignment
- (50 points) Add file system annotation to the Linux file
system. The standard Unix file system provides very basic meta
data, such as
the owner and the file creation time. For searching files, it would be
highly desirable to be able to add additional comments, label the
content and to provide display hints. (Services such as MacOSX
Spotlight provide such a feature, albeit outside the kernel.)
In this assignment, you will augment the
existing Linux file system
to add a set of search terms, a color and a media type string.
You could store the additional
information either as part of the inode
entry or in a separate datastructure. Since extending the inode
structure would require creating a new file system, you may find it
easier to store this information separately, indexed by the inode
number. You can assume that comments and content type are limited to
255
bytes. The content type is a string such as "text/plain" or
"application/pdf". You should also record when the information was last
changed.
When a file is removed, the additional
information should also be
deleted.
You will implement two system calls, one
to annotate a file, the
other to retrieve the annotation. Your system call
annotate()
should allow somebody who has write permission
to the file to annotate the file:
int annotate(char *filename, int color, char *comments, char *contenttype);
To retrieve the annotation, use
int statx(char *filename, int *color,
int comment_length, char *comments, int content_length, char
*contenttype);
Here, *_length
contains the
length of the buffer that
the caller allocates for this parameter. If there is no additional file
information, the function should return -1 and set errno
.
Your program must check the file
permissions and set
errno
accordingly. The color value is an RGB value,
with 8 bits each.
For testing, create a simple user mode
program that annotates a file:
annotate filename color comments content-type
The color should be specified as a
six-digit hex RGB value, such as
0305ab.
A new program, statx,
should display this additional
information, such as
statx test.txt
Change: Sun Feb 4 16:50:51 2007
Color: #0305ab
Comments: helpful hints for OS homework
Content: text/plain
If you have time and interest (sorry, no extra extra credit), you may also
want to modify the Linux ls command to use the stored
color information instead of the current highlighting algorithm.
Special Notes - Clarifications
- Your VMWare directory is not backed up. For safety's sake,
make a
copy of your changes — not the whole kernel tree! — on
another machine.
- If two people boot the same virtual machine at the same time, it will
corrupt the (virtual) disk. Please co-ordinate usage
with other members of your team.
What and How to Submit
-
You should create a
patch to store changes you've made to the kernel and to submit your
changes for this problem. If you've changed 50 lines of code, a patch
will be about 50 lines long. This is much easier to store, email, or
move around than the full 283,000-line source tree.
-
If you are using the KDB patch you applied from Homework 2 (which we recommend), your patch
should be from after
that patch is applied; i.e., KDB diffs should not
show up in the patch.
Git is a perfect tool to create a patch and apply it. First back
up your .config file, then do a ``make distclean''
in your changed source tree (you don't want object files, config
files, etc. in your patch). Then, run git format-patch -k --stdout v2.6.18
> ../homework6.patch.
Please run git commit for each step of the homework.
- Requirements for
Submitting Kernel Homeworks:
- Create git directory
- Do not include binary
files, patch files, test files, configuration files
in
the git directory
- Create ~/.gitconfig
- Write lots of detail in the git commit messages
- Patch should not
include binaries, KDB patch, or test code
- Create test directory
- Put test files in test directory
- In the README file, write how
to test, and what files are
included
- Write hostname, ip
address and group number for
vm in the homework_work.txt
file
- Shutdown VM when done, select the exact homework kernel to boot
- File names should follow
convention given in the instructions
- For the kernel programming project, a gzipped tar file of all
your kernel-related work. The filename should be HW6.kernel.group[num].tar.gz.
For example, if your group is 12, your
submission filename will be HW6.kernel.group12.tar.gz.
- For the kernel programming project, each member should post a
homework_work/homework_notwork.txt file using the following naming
convention: HW6.uni.[not]work.txt.
For example, if your UNI is abc123, and your project does NOT work, it
should be named HW6.abc123.notwork.txt
References