On Wed, Sep 01, 2004 at 05:37:05PM +0200, Ivan Popov wrote:
> On Wed, Sep 01, 2004 at 10:37:48AM -0400, Jan Harkes wrote:
> >  The Coda kernel module detects an open, sends the request to venus,
> >  venus opens (and optionally pins) a file in cachefs and fills it with
> >  the data. Then it passes the still open filehandle back to the Coda
> >  kernel module which keeps it around until the last reference
> >  disappears. Then the Coda kernel module sends the file release upcall
> >  and if it was opened for writing, venus reads directly from cachefs and
> >  writes the modified data back to the servers after which it unpins the
> >  file.
> > 
> > The only thing then is to replace the flag we use to indicates whether
> > we need to fetch the data or not with a stat(2) or access(2) test on the
> > container in cachefs.
> 
> With other words, we could make Venus life a bit easier, avoiding care
> of cache reclaimation. Think, it can work even on systems without cachefs.
> 
> If we run a separate daemon, which guesses how long each file in the cache
> was not useful, it could do efficient garbage collection, and make
> intelligent decisions based on available diskspace.

When thinking about how venus and cachefs would interact, I actually had
been thinking in that direction as well.

There are of course a couple of things that are easier to track in the
kernel. The kernel can keep an LRU, the daemon might just get away with
looking at the atime. Hoarding could trigger an access (updating the
atime) periodically to indicate that the cached file is more interesting
to us compared to than non-hoarded files.

Then the pinning, the daemon can't see if files are actively opened, or
whether venus is interested in keeping them around a bit longer. It
might be possible to use flock or something to lock files. I think that
even when the container file is write-locked, our kernel module will
still be able to write through, because those locks end up on the Coda
inode instead of the container inode.

> It does not have to have a persistent state, if we can afford a rescan
> at startup. The scalability would be limited by the time a stat()
> system call takes. Otherwise reading say 1000000 filenames is just several

Essentially venus is already calling stat on every container file to
check for inconsistency between RVM and the files in venus.cache. Since
locks are lost across reboot, venus would only have to re-lock any files
that are pinned down by a CML entry on startup although the daemon will
have to wait until this is completely done!! When restarting without a
full reboot we will have to check every file in the cache for stale
locks first.

So flocks might not really be the best solution for pinning just yet.

Jan