(Illustration by Gaich Muramatsu)
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. JanReceived on 2003-05-30 11:57:51