I can finally stop saying 'already fixed in CVS', because there is a
new release,

    Coda-6.0.0

Why bump the major version? Mostly as a big warning, there are a couple
of changes that make the upgrade non-trivial. It is important to read at
least the first part of this announcement before installing things as
it will otherwise probably break your setup.

New features

- Realms (aka. cells)
    This allows a Coda client to connect to multiple administrative
    domains at the same time. As a nice sideeffect this significantly
    reduces client configuration, as we no longer need to configure the
    client to connect to a specific set of rootservers and such. Because
    the top-level directory is dynamically created it also removes any
    chance of getting a (difficult to repair) conflict on the /coda
    mountpoint and it makes the initial mount a lot faster.

    Realms won't be visible until they are accessed. An 'ls' or 'cd'
    into something like /coda/testserver.coda.cs.cmu.edu should do the
    trick.

 ** Coda clients will need a new kernel module that supports 128-bit
 ** file identifiers instead of the old 96-bit version.

    ftp://ftp.coda.cs.cmu.edu/pub/coda/linux/kernel/linux-coda-6.0.0.tgz
    is a package that can build this new kernel module for linux-2.4.xx.
    I've got patches for Linux-2.5 and FreeBSD-current and a new coda.sys
    for WinNT/2000/XP, but I'm not sure where to put them just yet. At
    some point I'll probably also start collecting prebuilt binary modules
    for various distribution kernels.

- RWCDB
    The user and group databases on the server are no longer stored in
    libdb-1.85 format. It became increasingly difficult to actually
    find a truely db-1.85 compatible library on current Linux systems
    and the db2/db3/db4 libraries are really overkill for the job.

    RWCDB is nothing more than a simple hash lookup table with some
    support to add and remove entries from the hash. It was inspired
    by Dan Bernsteins' CDB database and in fact uses the same on-disk
    format.

 ** Before upgrading your old servers, you have to dump the existing
 ** user and group data into a simple text format with the old pdbtool.
 **     scm# pdbtool export coda.users coda.groups

    When the new server is installed, simply run
	scm# pdbtool import coda.users coda.groups

    If you have multiple servers, add prot_users.cdb to /vice/db/files
    that way the other servers will get the new user/group database.

These two changes are really the big ones that make the install of 6.0.0
not trivial. For the rest, 

 o  New clients can still use old servers,
 o  New servers can serve just fine to old clients.
 o  Server RVM is unchanged.
 o  Client RVM has changed, so venus will need a reinit.


More features

- LKA (Lookaside caching)
    A server can optionally return SHA1 checksum along with file
    attributes, the client can then use a local lookup table to search
    for an identical file on the local disk (or a USB dongle).

    Very useful if you need to reinitialize a client, but do not want to
    refetch all the data across a slow dialup link. Just move the old
    venus.cache aside and generate an index. Reinitialize the client and
    pass it the index and pretty much all files will be found locally in
    the old cache.

    Interestingly enough, adding this feature didn't break anything.
    Old servers simply won't return a SHA1 checksum so the client will
    fall back to fetching everything across the net.

- Path based volume naming
    When a client encounters a mountpoint without a volume name it will
    use the path leading up to the mountpoint as the volume name.
    That sounds more complicated than it is. Example,

    cd /coda/testserver.coda.cs.cmu.edu/playground
    cfs mkm foo
    ls foo	  # triggers a lookup for a volume named "/playground/foo"

    But all the old methods to mount volumes still work. So move along,
    nothing to see ;)

- Clients and servers no longer rotate their logs on startup.
    They do reopen the logfiles when receiving a SIGHUP, so it should
    not be too hard to use logrotate or a cronjob to set up an automatic
    daily rotation schedule.

    To avoid too much confusion and enormous logs when you do not have a
    logrotate setup both venus.init and startserver call scripts that
    perform simple logrotation (coda-client-logrotate and
    coda-server-logrotate).

- Perform /coda mount from a child process.
    We already needed this on Linux for a long time to avoid deadlocks
    as there are upcalls while /coda is being mounted. Now both NetBSD
    and FreeBSD do this as well.


Bugfixes
- Several reintegration and server-server resolution fixes.
- Fixed @sys/@cpu expansion in symlinks.
- Fixed bufferoverflow during backup when the server wasn't set up to
  use /vice for administrative files.
- Yet another flavor of devfs supported.
- We leaked a couple of filedescriptors during volume salvage on the server.
- gcc-3.2 and some -3.3 compile fixes.
- Pretty much removed the server dependency on VSG numbers, the VSGDB
  file is only used by createvol_rep.


RPC2-1.16 
- Now internally supports >2GB files, however we're not really using 
  this new capability in Coda yet.
- Re-added a lost lseek that was causing truncated backup files.


RVM-1.8
- More portable detection of fdatasync availability.
- Some more memory initialization fixes, and passing an actual iov
  struct to readv/writev instead of something that looks like it.


Right now I have source tarballs and SRPMs on ftp.coda.cs.cmu.edu.
Binaries will trickle in over time, Redhat-5.1 is already there, I've
got both debian-stable and -unstable ready, but there is only one debian
subdirectory to put them so I will have to reshuffle the debian download
paths a bit. The Redhat-8.0 build was successful, so that will probably
show up before the weekend as well.

That seems to be it for now, there are of course a lot of little details
how to use these new features that I have not mentioned in this
announcement, but most of that information has already been mentioned or
discussed on the codalist mailinglist and I'm sure we'll discuss it more
as people actually start using 6.0.

Jan