Mds - dumpability¶
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).
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
Then we wire them up to admin/dev comamnds to dump cache and other in-memory state.
- 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)