[OpenAFS-devel] Re: Change in openafs[master]: cmdebug -dcache

[Jeffrey Altman]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig59B24C7E1730ED8C57706A98
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

cmdebug is a very OpenAFS implementation specific tool and protocol.
When I implemented the cache manager rpc support for it I found that
there is simply not a good mapping for all of the data from the Unix CM
to the Windows CM.  I suspect there would be a significant challenge
supporting Arla and kafs as well.

The purpose of cmdebug (for the most part) is to gain a real time view
of the internals of the cache manager.  As such I question whether such
a tool should be standardized.

The existing cmdebug protocol also has significant limitations.  It is
restricted to 32-bit pointer values, 32-bit FIDs, 32-bit data versions,
32-bit time, and cannot describe the callback server by UUID.  I am less
concerned than Simon is regarding the security implications of report
cached buffers.  I think we are already leaking too much information by
having the cmdebug RPCs on by default.  What I am concerned is that
querying all of the buffer status info via an RPC interface such as
cmdebug is unwieldy.  An 8GB cache of 1K buffers (as in the Windows CM)
would require more than 8 million RPCs.  It would simply take too long.
 It is for this reason that the Windows CM has "fs memdump" which
produces a local log file containing all of the status information for
each of the data structures in the cache (cells, volumes, objects,
buffers, users, acls, servers, etc.)

I do believe that the cmdebug interface requires updating.  However, I
think it needs to be done on a per implementation basis.

Jeffrey Altman


On 1/24/2011 4:03 AM, Hartmut Reuter wrote:
> Simon Wilkinson (Code Review) wrote:
>> Simon Wilkinson has posted comments on this change.
>>
>> Change subject: cmdebug -dcache
>> ......................................................................=

>>
>>
>> Patch Set 1: (2 inline comments)
>>
>> The new GetDCacheEntry RPC and its associate structure needs to be
>> standardised, and a proper code point allocated. It should be pretty
>> easy to
>> put together a draft describing this for the afs3-standardisation list=
=2E
>=20
> Ok. Before spending much time on writing a draft I wanted to present
> this simple addition just by showing the few lines of code.
>>
>> I'd also like to see some consideration of the security consequences o=
f
>> publishing the contents of the disk cache to anyone who asks, but that=

>> can be
>> done as part of the standardisation discussion.
>=20
> I think all the information about which files have been seen on the
> client are already visible wich "cmdebug -long". The only additional
> information is which chunks of the files are actually cached. Perhaps
> one could create a switch on the client to disable both RPCs for sites
> which have security concerns.
>>
>> .................................................... File
>> src/fsint/afscbint.xg Line 125: ) =3D 65540; Has this code point been
>> allocated
>> by the registrar?
>=20
> Not yet, I first wanted to see the reaction of the community...
>>
>> .................................................... File
>> src/fsint/common.xg Line 86: Whitespace
>>
>> -- To view, visit http://gerrit.openafs.org/3743 To unsubscribe, visit=

>> http://gerrit.openafs.org/settings
>>
>> Gerrit-MessageType: comment Gerrit-Change-Id:
>> Ia7cb57bbc3686def297de4cacd3fcf519e4dd51f Gerrit-PatchSet: 1
>> Gerrit-Project:
>> openafs Gerrit-Branch: master Gerrit-Owner: Hartmut
>> Reuter<reuter@rzg.mpg.de> Gerrit-Reviewer:
>> BuildBot<buildbot@rampaginggeek.com> Gerrit-Reviewer: Simon
>> Wilkinson<sxw@inf.ed.ac.uk>
>=20
>=20


--------------enig59B24C7E1730ED8C57706A98
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQEcBAEBAgAGBQJNPcZKAAoJENxm1CNJffh4kHMIANA68EWVTxcOWpQb9HmLOCZR
l5p96rcZVpcitx3U8YS3G7Hv+hhkbh3+ndvHiyCWZsOwtigW3eLJO5FhGT7fx1rB
M/1YKTE7ODbuh/fUd7xda4v7fyJ5FlCI6/IpoTVcE62YkKP1k0VBpxzsQcH+GAnn
5Ai2MurA6LoP+GJEH5H7EGBlpNewLFmnhVFqyDgqF6VoeiUbtpATzM4c6c4e8gVg
ucZCS5eSRMLuhVR2U+syElZj1lt14XODmd3j+wVzPU1Gx5COz5kx1frEo7BRcWIs
/VGO4rriqJPdXtoQwcTXPuMepD/i7oMBX7R8wJeJZBQ8pPU8liCoywGBqa94Jo4=
=BH6w
-----END PGP SIGNATURE-----

--------------enig59B24C7E1730ED8C57706A98--