[OpenAFS] cache performance

[Neulinger, Nathan]

At one point, I was considering trying to merge the cache debugging
tools with fs, to add a root-only "fs dumpcache" command.=20

Not sure if this would be an ideal way to go about it.=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 9:22 AM
> To: openafs-info@openafs.org
> Subject: Re: [OpenAFS] cache performance
>=20
>=20
> >>>>> "Nickolai" =3D=3D Nickolai Zeldovich <kolya@MIT.EDU> writes:
>=20
> Nickolai> Well, I thought this was the behavior for a long=20
> time now, but since
> Nickolai> you mention it, hm...  It looks like in 3.5p2,=20
> Transarc added noatime
> Nickolai> code to the Solaris port (osi_DisableAtimes() in=20
> SOLARIS/osi_file.c),
> Nickolai> and to Linux (in osi_UFSOpen() in=20
> LINUX/osi_file.c).  But something
> Nickolai> seems to be still updating the atimes, as I'm=20
> seeing recent atimes
> Nickolai> on most V files in my AFS client caches.
>=20
> Nickolai> So, although there's code that claims to disable=20
> atimes, empirical
> Nickolai> evidence suggests that it's broken, and atimes are=20
> being updated
> Nickolai> anyway (not a big surprise for Transarc/AFS code). =20
> Given that you
> Nickolai> are relying on atimes, I'm a bit hesitant to "fix"=20
> it, esp. lacking
> Nickolai> good performance reasons to do so.
>=20
> It would not be the end of the world if we lost this functionality,
> and given the weak performance of the AFS client (generally,
> anecdotally speaking) anything that improves performance would most
> likely be the right trade off.
>=20
> >> The reason we have this code is that we analyze the=20
> contents of ALL of
> >> our clients caches (yes, I'm not joking, we really do), and procude
> >> enterprise wide reports on who is accessing what volumes.  This has
> >> proven very useful.
>=20
> Nickolai> Would a combination of cmdebug and server-side logging be a
> Nickolai> reasonable alternative?
>=20
> Well, what I really want is a way to cleanly extract this inforamtion
> from the servers.   Any audit that depends on automated tasks running
> on clients is guaranteed to NOT give you 100% coverage.  =20
>=20
> The server's the right place to do this, of course, and eventually, we
> want to look into significantly enhancing the server side client
> statistics, and the mechanisms for extracting them.
>=20
> If I have to audit the client, I don't care *how*, provided I can get
> at the necessary information.  If cmdebug can give me a comprehensive
> summary of what volumes are in the cache, I'll rewrite our code.
>=20
>=20
>=20
>=20
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>=20