Thanks to Allison for sending me her notes so I could get the team assignments, etc. right.Today, we are starting on our project: an NFS file server based on NFS version 2. You will put together many of the concepts of the course, come to grips with some rather intricate C code, and code up something fun and useful!
You will need to refer to documentation for CVS and the RFC 1094 NFS Protocol Specification. Look back at the RPC notes, too. You may find other useful reference on the course Resources page or on your own. If you find something really great, let me know, and I'll add it to the Resources page.
Recall that the project code is to be kept under CVS control. Do not keep your code private except for testing/debugging/experimenting. When you are done working, commit your code so others can use it or further debug and refine it.
We will begin with a read-only file system, that is, we will start with the NFS server procedures that do not involve writing to the server file system. That means that you must implement the following functions in the first version:
| Function | Priority | Team |
|---|---|---|
nfsproc_null_2_svc() |
none — deprecated | |
nfsproc_root_2_svc() |
none — deprecated | |
nfsproc_getattr_2_svc() |
1 | Tasha and Lili |
nfsproc_statfs_2_svc() |
1 | Tasha and Lili |
nfsproc_lookup_2_svc() |
2 | Kate |
nfsproc_readdir_2_svc() |
2 | unassigned |
nfsproc_read_2_svc() |
3 | unassigned |
nfsproc_readlink_2_svc() |
3 | unassigned |
For the second version, we will implement as many of the following NFS procedures as we have time for (and that may be zero):
nfsproc_setattr_2_svc() |
nfsproc_write_2_svc() |
nfsproc_create_2_svc() |
nfsproc_create_2_svc() |
nfsproc_remove_2_svc() |
nfsproc_rename_2_svc() |
nfsproc_link_2_svc() |
nfsproc_symlink_2_svc() |
nfsproc_mkdir_2_svc() |
nfsproc_rmdir_2_svc() |
We will ignore nfsproc_writecache_2_svc().
All the above functions should go in a new file, perhaps
called wfsv0.c. There is no need to define
a .h for these defitions: they are included in
the rpcgen-produced file
named nfs_prot.h. wfsv0.c
should not contain a main() function —
that's in nfs_prot_svc.c, which is also generated
by rpcgen. It is worth understanding the dispatch code
in nfs_prot_svc.c to see how it calls the functions.
It's interesting, and it shows how the RPC and XDR frameworks fit
together with your code (you don't have to worry about XDR at all).
The only changes we need to make to nfs_prot_svc.c
involve the main() function. This is where we will add
support for our arguments. Your program will be called like this:
wfsv0 root_path [-p portnum]
Kate will add the port request support, which will involve looking up
the arguments for the TCP and UDP registration code already there.
(Kate: Do TCP first.)
In order to get these server functions to work, we need to have an implementation of a file handle datatype. Allison and Ayla are the file handle team.
File handles are opaque names for server file system objects (files
and directories) that are passed to the client. They are then used by
the client to access those file system objects on later calls. There
is a slight wrinkle: Version 2 of the The file handle team will create files We also discussed cookies and how they will be used for reading
files and directories.
mount protocol
uses an initial file handle to perform statfs
and getattr requests. This initial file handle is not
chosen by our code, and we will simply store it away for future
reference.
filehandle.c
and filehandle.h. There will be a function to call on
first contact (can call it save_root_fh()
or fh_init() or something appropriate). This function
should also save away the current time for use in our own file
handle representation. Alternatively, these functions split in two
and one the time could be saved when the server is started. In
addtion, the file handle module will export fh_to_path()
and make_fh() functions.