Coda File System

Re: how do I increase my venus cache?

From: Jan Harkes <jaharkes_at_cs.cmu.edu>
Date: Mon, 27 Aug 2001 12:58:00 -0400
On Mon, Aug 27, 2001 at 10:01:59PM +0930, Brett Lymn wrote:
> According to Steffen Neumann:
> >
> >Yes, you need to -init. 
> >Afterwards the DATA container should be size 100M.
> 
> Nope, it is only 2.2Meg!

Actually the DATA segment will be about 10% of the cache-space, so with
100000 "diskblocks" it will be approximately 10MB.

If it is only 2.2 MB, the available cache space would be about 22000.

> >What about du -sh /coda/whatever while connected, how much does it
> >show ? 
> 
> About 2.8Meg

On newer kernels 'df' will give some useful information.

# df /coda
Filesystem           1k-blocks      Used Available Use% Mounted on
Coda                    250000      4178    193262   3% /coda
			^ configured client cache size
				    ^ non-replaceable objects
					    ^ completely free

Actual space taken up by objects in my cache is 250000 - 193262 = 56738


# df -i /coda
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
Coda                   10416    9765     651   94% /coda
		       ^ max fso's (derived as cache-space / 24KB per file)
				^ totoal # of cached objects
					 ^ available objects

IUsed and IFree don't add up because there is a small amount of reserved
objects that can only be used during repair.

> >I don't know how coda handles sparse files, but are there files like
> >open("/coda/somewhere"); seek(+30MB); close() ?

It doesn't.

> This is on a NetBSD 1.5-ish machine running 5.3.5, I have plenty of
> free diskspace on the machine.

Ah, 5.3.14 contained a patch that avoids unfair reclaiming. What happens
is that objects were given a random tie-breaker when they were created
(first cached), to aid in sorting the priority queue. When objects have
equal 'weight' and the ones with low random numbers are evicted. This
actually turned out to be unfair, because the cache becomes populated
with objects with high random tie-breaker numbers which are pretty much
persistent (i.e. some big tarball that was unpacked 3 months ago might
still be cached). I'm almost sure that your cache is not overfilled,
but that the wrong objects are being evicted.

Jan
Received on 2001-08-27 12:58:12