Coda File System

Re: Newbie Question - hoarding files

From: Jan Harkes <jaharkes_at_cs.cmu.edu>
Date: Wed, 5 Feb 2003 21:54:13 -0500
On Wed, Feb 05, 2003 at 04:35:32PM +0000, paul.rogers_at_mowlem.com wrote:
> How often does hoard need to be run?  Whenever new files are added?

The hoardfile (or profile) contains descriptions of which paths the user
would be interested in, something like,

c(lear)
a(dd) /coda/usr/jaharkes 600:c+
a(dd) /coda/usr/jaharkes/Mail 500:d+

I typically use the commands abbreviated, but the full 'clear' and 'add'
should work as well. The command is then followed by a pathname. Then
the 'hoard priority' which is used to decide which files are more
important when the cache fills up. The c+ and d+ are there to inform
hoard whether to propagate the priority to just children of the
specified directory, or recursively to the whole subtree underneath that
path.

Since venus stores the hoard profile in recoverable memory, it will
survive when the client is stopped and restarted. As callbacks are
received, the objects are refetched during the automatic hoardwalk and
any new objects that might have been created by other clients will be
discovered.

> I intend to hoard all the files on the clients(to provide redundancy
> for a set of web servers).  If this is done presumably the venus.cache
> directory will take up the most room on a disk. It would therefore be
> best to use this as a mount point for a seperate drive.  
> 
> Any thoughts?

There is so much that could possibly be improved in venus, that I really
haven't considered playing around with moving RVM log/data and container
files to different spindles. Their locations are all configurable in
/etc/coda/venus.conf, but I don't think it will matter much at the
moment.

There are some other ways to improve performance. A coda client locks on
a per-volume basis. As a result, concurrent open and close system calls
for files in the same volume can only be handled in sequential order. If
files are cached locally the overhead shouldn't be too high, but when
updated versions are fetched it becomes noticable. Actual read and write
operations will be mostly parallelized because we never need to leave
the kernel and it depends only on how the filesystem that holds the
container files deals with locking.

Jan
Received on 2003-02-05 21:55:37