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. > > 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 of >> publishing the contents of the disk cache to anyone who asks, but that >> can be >> done as part of the standardisation discussion. > > 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: ) = 65540; Has this code point been >> allocated >> by the registrar? > > 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<reu...@rzg.mpg.de> Gerrit-Reviewer: >> BuildBot<build...@rampaginggeek.com> Gerrit-Reviewer: Simon >> Wilkinson<s...@inf.ed.ac.uk> > >
signature.asc
Description: OpenPGP digital signature
