[OpenAFS] cache managers on openAFS clients NOT caching

Kristian kristian@hitech-sanita.it
Thu, 30 Sep 2004 18:06:01 +0200


Sorry about that. I replied personally by mistake... just hit the reply
button as usual! :)

Anyway.. I managed to get a bit further with my debugging of the
openafs-client (i.e. cache manager).

I also tried deleting the contents of the cache as you suggested, but I
am basically getting the same result: everytime I stop the cache manager
all the cache contents are ignored upon restart. 

I have used 

	cmdebug 

to see exactly how the cache manager sees the files in the cell. I have
re-initialized the cache and put mozilla-firefox in a read-only volume
in my AFS cell mounted on 

	/afs/myafscell.com/firefox/

Then launched the program by typing /afs/myafscell.com/firefox/firefox.
At this point, from my client (with IP 192.168.0.10) I typed:

	cmdebug 192.168.0.10 -long | grep expires

and the output I get is:

    callback 00000000   expires 0
    callback d1874920   expires 1096563917
    callback 00000000   expires 0
    callback d1874920   expires 1096563917
    callback d1874920   expires 1096563917
    callback d1874920   expires 1096563917
    callback d1874920   expires 1096563917
    callback d1874920   expires 1096563917
    callback d1874920   expires 1096563917
    ...
    ...
    ...
	<a few more others with the same expires value>

1096563917 corresponds to Thu Sep 30 19:05:17 2004... about 2 hours
after execution. I used calctime.c to extract this information.

At this point I closed firefox and stopped the cache manager... then
started it up again leaving the cache untouched. Most surprisingly if I
issue the same cmdebug command, all the callbacks are gone. If I
remember correctly, the cache manager doesn't fetch files from the AFS
server if the file's callback is still valid! If the callbacks aren't
there upon restart, the cache manager is definitely doing the right
thing, which is fetching the files from the server.

I now have two doubts/questions and hopefully somebody out there will be
able to shed some light:

	1) how can I extend the validity of a callback? I would actually
	   like to configure my cell to serve read-only files with
	   unlimited expiration time... callbacks should be broken
	   by the server ONLY when changes are released.

	2) is it possible to configure the cache managers to keep 
	   track of all the callbacks stored even after a restart?

Thanks for your help so far Derek.


Il mer, 2004-09-29 alle 20:12, Derek Atkins ha scritto:
> Please be sure to CC openafs-info on all replies.
> 
> One way to test whether the cache is caching or not is to start AFS
> with NO cache and compare it to starting AFS with a primed cache.  You
> can clear the cache by "rm /usr/vice/cache/*Items" (make absolutely
> sure that AFS is NOT running when you execute this command).  Then
> when you start AFS it will have no cache.  I bet it takes much longer
> to execute your program with an empty cache than it does with the
> primed cache.
> 
> -derek
> 
> Kristian <kristian@hitech-sanita.it> writes:
> 
> > Hi,
> >
> > I did expect stat information to be looked up every time. I am sure
> > inode data has not been changed because the executable I am testing on
> > is in a read-only replicated volume which has not been modified... not
> > even its rw counterpart.
> >
> > I would expect volume/stat information not to generate much network
> > traffic and to be fetched very quickly. I have used afsmonitor to keep
> > an eye on the number of fetches and a network grapher to see the amount
> > of traffic generated: the number of fetches increases rapidly by about
> > 100 (don't have the exact figure right now) and the amount of traffic
> > shown by the grapher is equivalent to the first ever run of the
> > executable. 
> > I understand this is not a very accurate way of analysing performance
> > and AFS expected behavior. Is there a better way to achieve this? I have
> > configured a squid web proxy server once and its access log file is
> > exactly what I would be looking for: simple messages like
> > 	
> > 	TCP_HIT	: for file in cache
> > 	TCP_MISS: for file NOT in cache
> >
> > Anyway... I thought that it might be a clock synchronization issue... my
> > clocks weren't perfectly sync'd. After fixing that it is still behaving
> > like this.
> >
> >
> >
> > Il mer, 2004-09-29 alle 17:52, Derek Atkins ha scritto:
> >> Hi,
> >> 
> >> The stat cache is not stored on disk, so it will always go back
> >> to the server for stat information after a reboot.  However if the
> >> inode data has not changed it should not need to refetch the data
> >> across a reboot.  Are you sure you're seeing data re-fetch and not
> >> just volume/stat information?
> >> 
> >> -derek
> >> 
> >> Kristian <kristian@hitech-sanita.it> writes:
> >> 
> >> > Hi There,
> >> >
> >> > I have set up an AFS server and everything works correctly. Clients
> >> > running the cache manager can connect and correctly access files for
> >> > which users have been authorized.
> >> >
> >> > However, on client reboot, and thus on cache manager restart, it seems
> >> > that the cache stored on disk is not being used at all. Basically, when
> >> > I execute a binary stored in my AFS cell it gets copied into my local
> >> > disk cache, but after reboot, even though the cache manager startup
> >> > script says that some files in my local disk cache are "not empty", I
> >> > can tell that it is still fetching the very same executable from the
> >> > only AFS database machine. Is there anything in particular I should be
> >> > looking at?
> > -- 
> > Kristian <kristian@hitech-sanita.it>
> > Hi.Tech srl
> >
> >
> >
-- 
Kristian <kristian@hitech-sanita.it>
Hi.Tech srl