Ceph

h1. Mds - dumpability

h3. Task Name: 

mds: dumpability

h3. Size: 

M

h3. Skill: 

beginner

h3. Mentor(s):

"Sage Weil":mailto:sage@inktank.com

h3. Components: 

mds, common/Formatter

h3. Description:

A 'dumpcache <filename>' command will dump all inodes, dentries, and dirs to a file using the operator<<() methods.  This is a good start, but only captures what is exposed by those methods--not all structure fields.

All encodable objects (that go to disk or over the wire) include a dump(Formatter*) method that will generate structured json (or xml etc) output for debugging.  The in-memory only structures (like CInode, CDentry, CDir) don't have these (yet).

The admin socket infrastructure lets you query a running daemon from the command line (e.g., 'ceph daemon mds.a <command.') and get the output.  It is fully buffered (entire result is built in memory, then written to the output).

The Formatter class has JSON and XML implementations.  It is fully buffered (entire output is generated in memory, then written to the output socket).

We should add dump() methods to all important in-memory structures, including:

* CInode

* CDir

* CDentry

* Capability

Any dump should be recursive (i.e., dumping the inode will also dump the capabilities).  It should not following links, thoguh (dumping a dir shouldn't dump all dentries and inodes.... or should it?)

We should also capture other improtant state, like:

* MDRequest / Mutation

* Session

* LogSegments

Then we wire them up to admin/dev comamnds to dump cache and other in-memory state.

h3. External Documentation:

h4. Coding tasks

# mds: add dump methods to CInode, CDir, CDentry, Capability

# mds: add dump methods to Session, MDRequest, LogSegment

# admin socket dump commands

# tell dump commands (dump to a file)