On Fri, May 30, 2003 at 04:57:14AM -0700, Steve Simitzis wrote:
> two questions:
> On 05/30/03, Jan Harkes <jaharkes_at_cs.cmu.edu> wrote: 
> 
> >  ** 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.
> 
> is the linux-coda-6.0.0.tgz package equivalent to applying the
> patch coda-6.0.0/kernel-src/linux-2.4-coda.patch to my existing
> 2.4.20 kernel source tree?

Yes, it is mostly useful for people that don't build their own kernels.
It can build the 2.4 module with just a set of recent headers and
extracts the symbols from proc/ksyms

> > - LKA (Lookaside caching)
> >
> >     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.
> 
> is this process documented anywhere? i would really like to use this
> feature.

I thought I was somewhere on codalist, but I'm clearly wrong because I
can't find it.

Short story....

- I didn't know how badly the SHA1 checksum generation during getattr
  operations affects the server. It tries to cache as much as possible,
  but the checksums aren't stored in RVM. So you have to explicitly
  enable this feature on the server side.

    /etc/coda/server.conf
    allow_sha=1

- Generate an index on the client.

    mklka index.lka some/local/tree

  Mklka has 2 flags '-v' for verbose, and '-r' which uses relative paths
  in the lka file instead of absolute paths. This is useful for data
  that is on a removable device that might be mounted at different
  places.

  The index is a very simple (sha1, path-to-file) database, so if you
  remove a file lka will not find or. If you change some file and the
  checksum no longer matches, lka will not consider it a cache hit and
  the client will have to refetch from the servers.

- Finally, tell the Coda client about the LKA index file.

    cfs lka --list		# List all known lookaside indexes
    cfs lka --clear		# Clear all lookaside indexes
    cfs lka +index.lka		# Add index.lka to the list of indexes
    cfs lka -index.lka		# Remove index.lka from the list

    cfs lookaside --clear +index.lka   # Clear indexes and add index.lka

  Ofcourse lka is just the shortcut for the actual command name
  'cfs lookaside'

> > 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.
> 
> woohoo!

I'm not 'whooing' yet. (except for not actually truncating backups)

- backup				- 2GB limit
- volutil dump volume dumpfile		- 2GB limit
- volutil dump volume > dumpfile	- Size is incorrectly reported
					  once we pass 4GB, but size is
					  essentially unlimited.
- merge					- 2GB limit
- volutil restore			- 2GB limit

However, now that rpc2 can deal with the required seek offsets of large
files, it isn't too much work to get the rest of the backup tools to
work with large dump files.

Jan