On Wed, Dec 31, 2003 at 04:56:13PM +0000, Joerg Sommer wrote:
> > other hand my client cache is probably about 10x larger as well which is
> > slowing down my client significantly because it has more objects to
> > manage and there are still codepaths that are O(n^2),
> 
> ouch. :)

These will be fixed over time, I already made one attempt that didn't
pan out too well so it's back to the drawing board until I understand a
bit better what is happening during cache replacement.

...
> coda daemon makes a lookup and reports to location. So coda demands a
> running userspace daemon (venus). But if it does lookups itself, it would
> be possible to use a disk cache for a readonly coda. So it would be
> possible to restart the venus daemon without interrupting processes
> accessing files readonly in the codafs.

We don't just do lookups for the right container file. There are access
checks and in the case of symlinks and directories the data isn't coming
out of a container file, but from RVM. (For directories we generate a
BSD/FFS compatible directory layout in a temporary file from the RVM
data)

It is possible to kill venus and 'reattach' it without unmounting the
filesystem, but that isn't really documented (or recommended) anywhere.
The problem is that we keep track of how many people have the file open
to avoid purging it from the cache while it is still being used, and to
only send the most recent version back (last writer closes). If you
restart venus and any files are still held open by the kernel, then this
accounting is screwed up and we get a negative refcount. We also lose
all open-for-write objects from the cache because we don't really know
their state, and any process that performs an operation that requires
venus's attention during the restart will get EIO error and typically
die. (but if you're really interested, the venus command line flag is
-allow-reattach)

> What's the reason for this? Currently, we're running a computer pool with
> diskless clients based on AFS. But AFS has the know disatvantages and we

If the clients are truly diskless, where is the local cache (and RVM)
stored? I know, silly question. But technically a truly diskless client
and the possibility of disconnected operation don't mix too well. If the
venus cache is stored in memory (ramfs/tmpfs) you really don't even need
RVM, it is possible to store all the metadata in malloc'ed memory which
isn't persistent and we essentially reinit every time venus is restarted
but the cache isn't persistent either (venus -rvmt 3).

If there is a local disk for venus.cache, RVM, and swap. Then I would
just keep the venus binary local as well. The layout of RVM is often
pretty closely tied to a specific Coda client version anyways. Upgrading
the venus binary on the local disk could first check whether there are
any pending changes to be written back to the servers. Then move the old
still running binary aside, install the new binary, create venus.cache/INIT
(triggers venus to reinitialize on restart) and reboot the machine...

Something like,

    lcl=/usr/sbin/venus
    rmt=/coda/<my-domain>/dist/usr/sbin/venus (or /initrd/sbin/venus?)
    cmp -s "$lcl" "$rmt"
    if [ $? -ne 0 ] ; then
	# install new Coda client binary
	mv "$lcl" "${lcl}.old"
	cp "$rmt" "$lcl"

	# make sure the new client will reinitialize RVM during startup"
	touch /usr/coda/venus.cache/INIT

	# check if anyone is currently logged in before rebooting
	users=`who | wc -l`
	if [ $users -eq 2 ] ; then
	    shutdown -r now "New Coda client installed, will be right back"
	else
	    shutdown -r +10 "Rebooting in 10 minutes for Coda client upgrade"
	fi
    fi

I'm not really sure how to check for pending reintegrations. The number
is available in venus, but I don't thing there is a way to pull it out
on anything but a per-volume basis.

Jan