On Tue, Jan 30, 2001 at 04:19:02PM +0100, Steffen Neumann wrote:
> Hi,
> 
> I have a few not too urgent questions around caching/hoarding.
> 
> 1) There is a not-too-intuitive issue with the permissions
>    of the hoard database, giving a "pioctl:add... Permission denied".
> 
>    For the casual user a message explaining who would be allowed
>    to write and/or who is logged on to /dev/tty1 would be great.

Only root (uid 0) and 'Console User' (the user who is supposedly logged
in locally) have permission to modify the hoard database. There seems to
be no simple and uniform way of discovering who logged in locally, so we
use the heuristic that the user would be logged in on tty1.

Ofcourse there is always the venus.conf option 'primaryuser' to
override this assumption.

> 2) I have the following hoardfile (quite generous,
>    as long as my cache can hold it ;-)
>    
> 	a /coda/homes/sneumann 600:d+
> 	a /coda/vol/ai 600:d+
> 	a /coda/vol/r 600:d+
> 	a /coda/vol/mysql 600:d+
> 
>    Doing a hoard walk gives me tons of 
> 
> [...]	  *** Missing/Invalid ***  /coda/vol/r/src/R-1.2.1/src/scripts/build d+
...
>    But looking at them explicitely finds'em:
...

Is the amount of data you are trying to hoard greater than the venus
cache size?

> 3a) What is the syntax of cfs lc ?
>     cfs lc is fine, but looking at a directory fails:
> 
> 	sneumann_at_Enceladus:/tmp > cfs lc /coda/vol/r
> 	/coda/vol/r: No such file or directory

Cfs listcache only works on a per volume granularity, so it is not
possible with the current ioctl to look at the cache state of a specific
directory (or file). You need to give the root of the volume.

cfs lc has a couple of options as well.

    -l		List cache in long format.
    -ov		Only list valid objects.
    -onv	Only list non-valid objects.
    -all	List all objects (default).

Valid objects have both valid status and valid data and can be used
without going through the servers. Non-valid objects have received a
callback, or were affected by a connectivity transition such as server
reconnection and need to be revalidated.

> 3b) What is the semantics of cfs lc output ?
> 
>    There is files with/without a star,
>    even after the hoard walk.

The star (in short format) indicates that the object either requires
revalidation whenever it is accessed, or that it is 'dirty' and needs
to be sent back to the server.

In long format, the output looks like

* dm ./xxx (0x7fnnnnnn.0xnnn.0xnnn)
^ ^^ ^	   ^
| || |	   |
| || |      - FID of the object
| || |
| ||  - path to object
| ||
| | - directory/symlink subtype:
| |     m - mounted volume mountpoint
| |     l - unmounted volume mountpoint
| |     / - volume root
| |     v - top level root (i.e. /coda)
|  - file type
|       d - directory
|       f - file
|       s - symlink
 - valid (' ') or invalid ('*'), i.e. does this object require server
   communication

Jan