On Sat, Mar 20, 2004 at 03:59:44PM +0800, Paul Patrick Carpio Prantilla wrote:
> I've been using coda for a few months now (I'm currently using 6.0.4 but
> am about to upgrade to 6.0.5), however I have a few questions regarding
> how the hoard command and it's priorities affect the HDB. Please correct
> my if I'm wrong, but my assumption is that once the venus cache is full,
> the cached objects with the lowest priority value assigned to them are
> automatically evicted from the cache to make room for a new incoming
> object. If this is so, I'm quite confused as to why a certain experiment
> I'm working on doesn't turn out results as I expect.

The hoard priority defines only the 'static' part. There is also a
dynamic part which depends on things like how recently the file was
accessed and the cost of refetching the object (size / bandwidth). I'm
not entirely sure how all of this is weighted (there are short, medium
and long-term weighting factors in the calculation) but it definitely is
often confusing and counter intuitive.

For my type of usage, a large file is typically a tarball, iso-image, or
mp3 file that once it is accessed really isn't important at all. But the
sheer size of these compared to f.i. the email messages in my maildir
folders and the weighing factors results in my client continuously
refetching the email if I don't use large hoard priorities (500 or
more).

> 1-1000 to the just-opened file. This priority is primarily based on the
> wireless connection strength (among other things) from the client to the
> server the opened file resides in. Thus,the weaker the connection
> strength...the higher the priority value assigned by hoard to that file.

So I guess that venus's filesize / bandwidth factor in the dynamic
priority already does a similar thing.

> My question is this: why is it that if I hardcode my program to assign a
> constant priority value (e.g 100) using hoard to all opened files from
> both servers...the script still finishes in around 14 minutes? I flush

Either venus is really messing up the priorities, or it is already quite
successful in trying to do the same thing.

> On another note, sometimes when hoard is called repetitively for long
> periods fo time..something like this happens:
> 
> Coda_pioctl: Venus return -4 for (0xf000001.0X1.0x)
> 16:28:23  Dispatchworker: Signal received (seq=6307)
> 
> I guess hoard wasn't meant to be used like this though...:)

The error (-4) is actually EINTR, and it happens whenever the kernel
receives a signal which aborts an active operation. Often an impatient
user typing '^C', or some process deciding that it waited long enough
and sending itself a SIGALRM.

However I just noticed that a couple of these showed up in the logs of
our webserver last night, and I'm sure I wasn't hitting ^C at 3am in the
morning.

Jan