(Illustration by Gaich Muramatsu)
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. JanReceived on 2001-08-27 12:58:12