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
