Hello all,

To introduce myself, I suppose I should say that I am more or less in
charge of the Coda project now.   So you can take this as a bit as our
official view (fwiw). First of all: THANK YOU FOR YOUR INTEREST IN Coda!

I felt it would be a good idea for me to respond to the flurry of messages
coming from the FreeBSD community.  I try to read all of them but can't
really reply right away to everything. 


A) Re: Coda FS: FBSD port done!, but development favors Linux
-------------------------------------------------------------

This is NOT AT ALL TRUE.  I can see how what I said evolved into this
statement, here is what I really said (or believe I said):

a) the FreeBSD port (2.2.5) is _almost_ done.  We have a working client,
the servers are playing up a bit. 

b) we DO NOT FAVOUR LINUX.  It is true that our servers start up 3 times
faster on Linux than on NetBSD 1.2.  It is also true that a fairly large
group of students from Yale is helping to implement Linux specific Coda
optimizations (which FreeBSD may already have).  It is also true that some
NetBSD people have been sending me very unfriendly messages about Linux. 
Finally it is true that a lot of high quality FreeBSD/NetBSD messages
have been sent to the Coda lists -- that's great. 

Please join the linux-coda lists (see www.coda.cs.cmu.edu).  Don't engage
in OS wars, or irrelevant criticism of other free or commercial operating
systems -- if it happens I'll start moderating the list.  We are just
interested in Coda.  The list will probably be renamed reflect its
NON-linux status.

We hate OS wars, and want Coda on all platforms particularly the free
Unices and the Windows platforms -- all using one code base.  A lot of
work remains to be done -- many features are not reliable enough,
performance and scaleability, useability and administration can be much
improved. Many good things come out of trying to just use Coda. Use our
test server, or set up your own.  If you happen to have time, by all means
send us patches.  Mail about difficulties to the list -- we'll try to
help.

c) YES, we are making a "CURRENT release for FreeBSD".  Bob Baron chose to
first do 2.2.5 and will soon start on current (vz. when the server works
and some other minor kernel issues have been sorted out).   I hope the
kernel code of this release can be accepted for inclusion in the FreeBSD
kernel. 


B) Inode calls.
---------------

For scalability these calls are desirable.  In fact we probably only need
iopen, istat, idelete and I'll try to remove iinc and idec (used for copy
on write vnodes). These inode calls are only used by the cache manager and
the servers and don't compromise security of the system, since they should
be restricted to root.

Ted Ts'o indeed said that Linus is probably against plain "iopen" -- and
rightly so.  Using the special names like 'I'N'O'D'E we can let it work
right with the VFS and dentry's etc while retaining most of the benefits
of speed.  For Coda this will just become an optionally supported
partition type.  

It should indeed be a mount option, or better perhaps something set with a
utility in the superblock, so that fsck knows about it too. (see the
messages of myself and Ted on linux-coda). 

C) Ext2 vs FFS vs Coda
----------------------

Coda needs much larger vnodes to deal with replication servers (among
others).  We also run in user space -- mostly and use proper RVM
transactions to guarantee (on all platforms) very high consistency on
metadata. Effectively we are a transactional, log based system on servers. 
We use file storage only for file data not for metadata.

On clients we also have transactions, but we don't flush them right away. 

We hope to implement write back caching where large groups of transactions
can reach the server and improve performance by eliminating many
transaction related fsyncs. 

It is unwise to speculate about the consistency guarantees which ext2fs
might offer to Coda versus ffs -- without considering RVM.  The Coda meta
data will be treated identically through RVM, on all platforms.  The file
data might be slightly more at risk in ext2fs (although I believe that ffs
and extfs mostly differ in the handling of metadata).

I hope this clarifies some of the recent discussions. 

Thank you very much for all your enthusiasm -- that makes us very happy of
course.

- Peter Braam -
Senior Systems Scientist 
Coda Project, SCS, CMU