I can finally stop saying 'already fixed in CVS', because now 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 that will 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