Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Clone this wiki locally
The Cooperative File System
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:email@example.com:/cvs login Logging in to :pserver:firstname.lastname@example.org:2401/cvs CVS password: _press return_ % cvs -d :pserver:email@example.com:/cvs co -P sfsnet
Once you have obtained these particular versions of the source, the normal build instructions ought to work.
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
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: firstname.lastname@example.org % 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
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
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.