(Illustration by Gaich Muramatsu)
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. JanReceived on 2003-02-05 21:55:37