Coda File System

Do I need hacked fsck?

From: Jim Carter <>
Date: Sun, 12 May 2002 16:20:20 -0700 (PDT)
I was very attracted to Coda because I often use my laptop computer
disconnected from my server, but I would like to have changes on the
laptop and the server be interpropagated without a lot of error-prone
scripting managed in detail by me.  I tried and failed to install Coda
about two years ago, and I tried again over the last week (2002-05-11).
This is coda-5.3.19, lwp-1.9, rpc2-1.13, rvm-1.6, installed on Linux,
SuSE 7.3 (kernel 2.4.16) with heimdal-0.4d. I used the module (can't
tell what version) that came with the kernel, rather than
linux-coda-5.2.3 from the web site.

I got it to compile (minus Kerberos).  I needed to hack the Makefiles,
though.  I've posted the diffs separately.  I was able to load the
kernel module, execute venus, and connect to the test server.  My
testing did not, however, get to starting the local server and creating

But in the manual section on setting up the server I found a
showstopper:  Coda uses pre-existing filesystem formats for user data
storage, e.g. UFS on Solaris, or on Linux, ext2 and presumably ext3,
Reiserfs, etc. etc.  But it creates files that are not in any directory,
and fsck for the respective filesystem formats has to be modified to
ignore that (only for the Coda filesystems), and the modified fsck is
not provided.

I notice in the mailing list archive that several sites seem to use Coda
in semi-production.  Have they hacked their fsck, or do they just hope
nothing goes wrong with the underlying filesystem?  Or has Coda been
modified to put all files in directories, even if not used by Coda?
Clearly it's not going to be feasible for you to hack the fsck for every
filesystem format that ever has been or ever will be invented.

"If you can't say something nice, don't say anything at all" :-)  I would
like to mention some aspects that I found to be positive:

As far as I noticed, there were no warning messages in compilation; the
only messages were about things that were truly broken.

The kernel module doesn't fight with devfs, and /dev/coda/0 appeared as
it should, when the module was loaded.  You can unload the module and
nothing seems to break.  This isn't the module mentioned as being
changed for 5.3.19 for better devfs support, which I couldn't find.

The test server is a really valuable resource for the community.  It
reduces the debugging work exponentially if the sysadmin can validate
his client against a known good server, before siccing it on his own
botched server configuration.  Venus seemed to recognize and adjust to
the slow data link (my wireless card is acting flaky again), though I
didn't notice a log message about a transition to weak connection mode.

I assume that illegal warez deposited by script kiddies with the Coda
Windows client are purged promptly.  Here's an idea, when quotas are
implemented: to use the test server, a user has to register on the web
site, giving his numeric UID and password.  A volume is created just for
him with a quota too small for "Attack of the Clones".  It gets tossed
after an hour or so.  Lacking quotas, it's probably sufficient to set up
the ACL in the user's directory with permission lidrwk -negative a, only
for the owner.  Maybe. (Interesting: I searched everywhere in the Coda
docs, including a HTDig search of the web site, and didn't find an
explanation of the ACL codes. I finally got them from

I was pleasantly surprised that Coda (venus) was not fazed by Network
Address Translation, and a pretty aggressive firewall both on the laptop
and the gateway, as provided by Linux 2.4.x iptables.  It would have
made total hash of a remote NFS mount, if I were brave enough
(security-wise) to try it.

The users manual was informative and pretty easy to use.  Though I
noticed a few unfinished sections, and your latex2html, or whatever
converter you used, was not kind to a few phrases, which I get the
impression are code examples within boldface subsection titles.  The
tables came out decent looking, as displayed by my browser, Opera 6.0b2
for Linux.  I'm surprised the crossreference IDs all came out as XXX.  I
would guess that you need to run LaTeX once, to create the aux file,
before executing latex2html, which doesn't know to do that.

James F. Carter          Voice 310 825 2897    FAX 310 206 6673
UCLA-Mathnet;  6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA  90095-1555
Email: (q.v. for PGP key)
Received on 2002-05-12 19:21:29