Re: tlug: CODA distributed filesystem

[Frank Bennett <bennett@example.com>]

"Stephen J. Turnbull" <turnbull@example.com> writes:

>     Frank> I have written up a set of notes on installation, which I
>     Frank> will happily send to anyone who wants them.
> 
> Post 'em, we[1] need more technical info on this list.  :-)

SOME NOTES ON BUILDING CODA

*** First: what is CODA?  Here's the announcement of the latest
release (search for *** to skip to the next section of these
notes):

This is to announce Coda 4.6.6.  
--------------------------------

Coda is a distributed filesystem with novel features such as disconnected
operation and server replication.  For many details about Coda see
http://www.coda.cs.cmu.edu. 

Coda currently runs on FreeBSD(i386), Linux(i386,sparc) and NetBSD(i386).
Ports to Windows(95,NT) are in progress.

What happened since Coda 4.6.5 our previous "stable" release?

- For this 4.6.6 release, Coda works on current versions of both FreeBSD
  and NetBSD platforms.  There is direct kernel support as well as lkm's
  for kernel features.  The packages/port system can be used to obtain
  and/or build Coda.  Coda is in the package/port tree under: 
	net/coda_intro, net/coda_client, net/coda_server, net/coda_doc

- We've also taken a couple of the fixes for various small, but annoying,
  bugs from the development version.

- We fixed (and probably broke) some things in the various server setup
  scripts, but they are better than before.

As always, this version is MUCH better than 4.6.5, try it!!

It has been released in binary form for:
 Linux binary rpm's
 FreeBSD 3.0 (a.out & elf) packages!
 NetBSD current pre-compiled packages

It can be found at: 
ftp://ftp.coda.cs.cmu.edu/pub/coda/[your platform]

Documention in cpio and rpm format:
ftp://ftp.coda.cs.cmu.edu/pub/coda/doc

For all other platforms and architectures:

		Use the source.
	ftp://ftp.coda.cs.cmu.edu/pub/src

By the way, we keep snapshots of our ongoing development here
as well.  So if you want to build/run the latest Coda check out
the 4.7.x branch.
-------------------------------------------------------------------------

What's next?  

The snapshots show you where we are going. Jan continues to fix
tricky bugs in Venus related to disconnected operation and reintegration.
The new directory code is still being improved.  We are also working
on clients for 95 and NT. 

Integrating more of the patches we've been sent (Thanks guys!).

---------------------------------------------------------------------

Have fun!

The Coda Group. 

Contacts:
Peter Braam, braam@example.com
Jan Harkes,  jaharkes@example.com
Bob Baron,   rvb@example.com

*** HOW CAN I RUN CODA ON TL 2.0?

The binary RPMs are reputed to be built for RedHat 5.0 and to
work also under 5.1.  But in case anyone wants to build CODA from
scratch, here are some notes about what I think I did to get
things up and running under TL 2.0, at least.

First, fetch the sources ...

  ftp ftp.coda.cs.cmu.edu

  cd /pub/coda/src

[or]

  cd /pub/coda/linux/SRPMS

Then either get:

   coda-4.6.6.tgz

OR get:

   coda-debug-4.6.6-1.src.rpm

and one of

   coda-fs-module-k2.0.32_c4.6.0-1.src.rpm
   coda-fs-module-k2.0.34_c4.6.0-1.src.rpm
   coda-fs-module-k2.0.35_c4.7.0-3.src.rpm

and the docs in the same subdirectory --- they won't tell you
everything you need to know, but the more docs the better, right?

I did my build using the raw sources, not the RPMs.  There are
warnings in the docs about the need to use quite specific tools
to do the build, including a CMU version of "make", but things
SEEM to have worked with the GNU kit in TL-2.0 (he said --- this
is still EXPERIMENTAL STUFF though, so don't trust it, or me, in
ANY case).

To build, I went to the top of the source hierarchy after
unpacking, and did a ./configure.  Then I did "make", and found
that the compile kept failing for want of headers that were
scattered throughout the sources.  Obviously some paths are
wanted, but I hacked things into compilable order with the
following script, run from INSIDE a directory ./include, which I
created at the top of the Coda source hierarchy:

#!/bin/bash
# File: make-includes
rm -f *.h
rm -f cfs/*.h
for h in lib-src/mlwp lib-src/special-includes rvm-src coda-src ; do
  for i in `find ../ -name "*.h" | grep $h` ; do
    ln -s $i
  done
done
mkdir cfs
cd cfs
for h in kernel-src/vfs/linux/cfs kernel-src/vfs/includes ; do
  for i in `find ../../ -name "*.h" | grep $h` ; do
    ln -s $i
  done
done
cd ..

CAUTION: you need to make a subdirectory ./include at the top of
the CODA source hierarchy, copy this script into it, cd to the
./include subdirectory and then run the script.  This script uses
"rm -f" --- DON'T run it from anywhere else!!!!!

You will now be able to cd .. and run make more successfully.
Things will fail again, once or twice.  The make generates a
couple of header files on the fly, which you need to pick up by
rerunning make-includes.  To do this, cd to ./include again and
run ./make-includes from that directory, then cd .. and type
"make" again.

Once everything's built, you can install with "make
client-install".

Next, you need to build the kernel module.  I think you need the
kernel sources that match your module source number.  There's
probably a script around in there somewhere that tells how to do
this cleanly, but to hack up a module I did (from the top of the
coda source hierarchy):
  
  cd kernel-src/vfs
  touch .prereq.ok
  cd linux
  ln -s ../includes linux
  make coda.o

It seems to work :-|.

Copy the module into your /lib/modules hierarchy, and do insmod
on it, then lsmod to be sure its made it into the running kernel.

There's a file that ships with the binaries that tells how to set
up the client and test its operation.  This is as far as I've
gotten.  Here's the portion on testing the client:

           On a client run the script /usr/sbin/venus-setup.

	     venus-setup <comma,separated,hosts> <cachesizeinkb>

           NOTE: the cache size should be at least 10000, but
           preferably more. 

           You can test your client installation by connecting to
           the testserver at CMU:
           
             venus-setup testserver.coda.cs.cmu.edu 40000

	   I strongly recommend you to try that first. 

	   Also test if your kernel module matches your kernel:

              insmod coda 
              lsmod coda

           should proceed without errors and show a Coda module 
           in the kernel.  If not recompile the kernel module, 
           read README.kernel-module. 

           Start Venus with
               venus &
           Follow the log with
               tail -f /usr/coda/venus.log
           Type 
               codacon 
           in an xterm to see the actions. 
	
	   You can turn up debugging with 
               coda-debug 4095 (see coda_linux.h for the bitmask)
               coda-trace 1
           (these set constants in /proc/sys/coda/?)
	
	   NOTE: Please make sure your have enough free space on the
                 filesystem in which /usr/coda/venus.cache resides for the
                 cache-size indicated.  That is, if you specify 20000 for 
                 for twenty-thousand kilobytes, this means you must have at
	         least 20MB of free on the partition containing venus.cache.

	   See above how to point your client at your own server.

I haven't gotten a server up yet --- I have to dust off an SS5
and install Linux on it, and string some extra disks off of it
first.  More later.

*** SO IT'S RUNNING THE CLIENT --- BIG DEAL

You're next question is likely to be something like, "Okay, I've
DONE all of that, and it all seems to work.  Now where's this
shared filesystem that everyone's been talking about?  Or is it
securely known only to the kernel, and not for use by outsiders
or something?  What's the deal?"

At the top of your file hierarchy on your machine, you should
find a directory /coda.  Cd down from here, and you're inside the
distributed filesystem.

*** HOW DO I SHUT THE DARNED THING DOWN?

Use "vutil -shutdown" to stop the client.  You should then always
explictly unmount the filesystem with "umount /coda"; if it
doesn't unmount when the server is stopped (it never seems to for
me), the mount will block the client the next time you try to
start it up.

Enjoy!
-- 
-x80
Frank G Bennett, Jr         @@
Faculty of Law, Nagoya Univ () email: bennett@example.com
Tel: +81[(0)52]789-2239     () WWW:   http://rumple.soas.ac.uk/~bennett/
---------------------------------------------------------------
Next Nomikai: 20 November, 19:30 Tengu TokyoEkiMae 03-3275-3691
Next Meeting: 12 December, 12:30 Tokyo Station Yaesu central gate
---------------------------------------------------------------
Sponsor: PHT, makers of TurboLinux http://www.pht.co.jp