On Fri, Jul 25, 2008 at 02:41:43PM -0700, Andy Valencia wrote:
> FYI, for FreeBSD 7.0 I found that the latest Coda stuff was in the ports
> tree, but this didn't include the kernel module.  All I could find on
> the kernel side was back an entire revision.  I was in an environment
> which already had Coda running, so I didn't want to drop back a rev.

I just checked and the Coda kernel module in FreeBSD 7.0 is correct and
current. There is a COMPAT_CODA_5 define to revert back to the older
interface, but if that is not defined it uses the current kernel-venus
api.

> I queried here, and didn't get a response.  So I'm assuming that
> tracking FreeBSD is not much of a priority.

I missed the mail, but even then it took me a while to figure out which
release FreeBSD 7.0 was the most current stable release, Coda support
was broken in the previous stable.

> So proceed with caution.  As far as I can tell, Coda doesn't scale to
> modern media sizes.

Depends on what you want to store. Coda doesn't scale well to millions
of files, but if the files are of moderate length (several megabytes
each, f.i. single track music files or digital photos) it has no problem
filling up a few hundred GB of disk space.

>		       And you will want a non-Coda backup system which is
> run often enough to stay very current.

I've been running Amanda myself, and just this week set up BackupPC,
which uses content hashes to avoid storing duplicates of the same data.
This is really nice when you backup up all available replicas of
replicated volumes because you only end up storing one copy as long as
the replicas are in sync. Of course it also revealed an issue where a
volume dump gets aborted when the socket buffers fill up and the volutil
process blocks while trying to write more.

> Sorry to sound so negative, but my experiences really didn't lead me to
> believe that Coda is ready for a production environment.

That's ok. I happen to use Coda for our web server, my email, and
various other people have found uses as well. But there are still
situations where it may not be as reliable. Partly this is because Coda
uses optimistic replication, and when that optimism fails it falls back
on heuristics to fix up any resulting conflicts. Those heuristics are
not all encompassing, directory resolution has gotten reasonably usable.

But there are still corner cases, one I know of and am working on is
when a file is created on one replica, we then store the data and try to
resolve the store operation. Because the other replica(s) have not yet
seen the create they don't recognise the file and we get a conflict.
Most of the time it works, because the parent directory (create
operation) is resolved first, but once in a while things happen in the
wrong order and we get a conflict.

So hopefully at some point we will be able to handle whatever problems
are triggered by your usage models as well.

Jan