[OpenAFS] cache performance

Neulinger, Nathan nneul@umr.edu
Fri, 25 Oct 2002 10:43:55 -0500


One assumption I see you making is that your cache isn't flushing.
Unless your cache is larger than your working set, you'll need to run
your scans repeatedly to insure that you have a good chance of catching
all the accesses.=20

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul@umr.edu
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216


> -----Original Message-----
> From: Phil.Moore@morganstanley.com=20
> [mailto:Phil.Moore@morganstanley.com]=20
> Sent: Friday, October 25, 2002 10:31 AM
> To: openafs-info@openafs.org
> Subject: RE: [OpenAFS] cache performance
>=20
>=20
> >>>>> "Nathan" =3D=3D Neulinger, Nathan <nneul@umr.edu> writes:
>=20
> Nathan> At one point, I was considering trying to merge the cache
> Nathan> debugging tools with fs, to add a root-only "fs dumpcache"
> Nathan> command.
>=20
> Nathan> Not sure if this would be an ideal way to go about it.=20
>=20
> OK, some more research and thoughts on this topic...
>=20
> Looking at the cmdebug code, and in particular, the AFSDBCacheEntry
> structure that is basically just pretty-prints (although, personally,
> I would not call that output "pretty"), I don't see that the cache
> manager maintains the last access data, or anything like it.
>=20
> However, I wonder if the cbExpires (obviously the callback expiration)
> couldn't be used to similar effect?  If I have data in my cache that
> hasn't been accessed in a while, one would assume that the callback
> expiration should be pretty old, right?
>=20
> Tactically, I should be able to use this to determine roughly when a
> volume was most recently accessed, based on the assumption that
> accessing the volume will refresh the callback.   Fair enough?
>=20
> The only issue I see is that cmdebug currently only prints the first
> 10000 cache entries, and I want them all:
>=20
>     for(i=3D0;i<10000;i++) {
> 	code =3D RXAFSCB_GetCE(aconn, i, &centry);
> 	if (code) {
> 	    if (code =3D=3D 1) break;
> 	    printf("cmdebug: failed to get cache entry %d (%s)\n", i,
> 		   error_message(code));
> 	    return code;
> 	}
>=20
> Damn, I hate hardcoded limits like that...  Isn't there a more elegant
> way to determine when we've hit the end of the list of cache entries?
> Loking at the RXAFSCB_GetCE, it seems to me that this will return 1
> when there's nothing to get, so is there any good reason not to have
> the cmdebug code loop until that condition is reached?  That is:
>=20
>     while (1) {
> 	code =3D RXAFSCB_GetCE(aconn, i, &centry);
> 	if (code) {
> 	    if (code =3D=3D 1) break;
>=20
> Seems to me a reasonable replacement for the missing access times may
> be readily available, if not entirely equiavalent.
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>=20