cfs

The Cooperative File System

Building CFS

CFS implements a read-only distributed file system. It depends on the Chord and dhash libraries, the SFS libraries, and the SFS loopback server (i.e. a running copy of sfscd). You must be using the full SFS libraries, not SFSlite. Since SFS has not seen a release in some years, Chord depends on code in the SFS repository that has not yet been released. You will need the latest CVS version of SFS-0.8pre.

You will also need an "old" verison of the Chord source-tree. This can be obtained via anonymous CVS or from one of the snapshots dated before 1 December 2006. Anonymous CVS works something like this:

 % cvs -d :pserver:anoncvs@cvs.pdos.lcs.mit.edu:/cvs login 
 Logging in to :pserver:anoncvs@cvs.pdos.lcs.mit.edu:2401/cvs
 CVS password: _press return_
 % cvs -d :pserver:anoncvs@cvs.pdos.lcs.mit.edu:/cvs co -P sfsnet 

Once you have obtained these particular versions of the source, the normal build instructions ought to work.

The loop back CFS client

To run the "real" client you'll need to have a "run in place" sfs directory; this allows you to run another copy of the sfscd daemon that is aware of CFS without disturbing your existing SFS setup.

The 'in place' directory can be thought of as a chrooted environment for SFS. SFSCD will read its config files from the etc directory inside this directory. To get started, untar this file which contains a skeleton runinplace directory. You'll need to modify the "etc/sfscd_config" file to point to your copy of chordcd (the Chord client). Modify the line that starts with "Protocol Chord" so that the given path points to /your/build/tree/chordcd/chordcd. To run-in-place you'll need to set some environment variables. I'd do it like this:

setenv SFS_RUNINPLACE /disk/su0/fdabek/sfs-fdabek/ setenv SFS_PORT 10000
setenv SFS_ROOT /sfsrewt

You should set the SFS_RUNINPLACE variable to point to your runinplace directory. The last two prevent you from interfering with the "real" SFS running on your machine. You may choose any valid port and mount point.

Inserting a file system

To test the client, first start up a lsd listening on "/tmp/chord-sock" (i.e. with -S /tmp/chord-sock"). Next run the sfsrodb command (be careful not run the one that SFS installs). If you don't already have a SFS key pair handy, you'll need to generate one.

%  sfskey gen -KP key_file 
Creating new key for key_file.
       Key Name: fdabek@supervised-residence.lcs.mit.edu
%  your/Chord-build/dir/sfsrodb/sfsrodb -s key_file -d dir_to_export 
sfsrodb: Database good from: 
 Thu Nov  1 16:44:55 2001
until:
 Fri Nov  2 16:44:55 2001
sfsrodb: exporting file system under IaLCvdNTyE8wX103EAQ2uMqMdYU

When sfsrodb completes it will print out what looks like a random string. This string is the unique identifier for the file system you've just inserted.

Running the client

Now, back in your runinplace directory, start sfscd. This time you do want the one in /usr/local/. sfscd must be run as root.

%  /usr/local/sbin/sfscd -d 
sfscd: version 0.5, pid 8178
chordcd: chordcd version 0.1 running under PID 8179
sfscd: not dropping privileges for debugging
nfsmounter: version 0.5, pid 8180
nfsmounter: mounted /sfsrewt
nfsmounter: mounted /sfsrewt/.mnt/wait

Using the client

Now you are ready to try out the client. If your SFS_ROOT was set to /sfsrewt, try something like:

ls /sfsrewt/Chord:[magic string]

you should see a listing of the directory you inserted with sfsrodb after you see a bunch of debugging garbage.