Mds dumpability » History » Version 1
Jessica Mack, 06/07/2015 01:10 AM
1 | 1 | Jessica Mack | h1. Mds dumpability |
---|---|---|---|
2 | |||
3 | h3. Summary |
||
4 | |||
5 | Expand the 'dump' command set so that a running mds can dump more state to a local file or unix domain socket for debugging visibility. |
||
6 | |||
7 | h3. Owners |
||
8 | |||
9 | * Name (Affiliation) |
||
10 | * Name (Affiliation) |
||
11 | * Name |
||
12 | |||
13 | h3. Interested Parties |
||
14 | |||
15 | * Sage Weil (Inktank) |
||
16 | * Name (Affiliation) |
||
17 | * Name |
||
18 | |||
19 | h3. Current Status |
||
20 | |||
21 | 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. |
||
22 | 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). |
||
23 | 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). |
||
24 | The Formatter class has JSON and XML implementations. It is fully buffered (entire output is generated in memory, then written to the output socket). |
||
25 | |||
26 | h3. Detailed Description |
||
27 | |||
28 | We should add dump() methods to all important in-memory structures, including: |
||
29 | * CInode |
||
30 | * CDir |
||
31 | * CDentry |
||
32 | * Capability |
||
33 | |||
34 | 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?) |
||
35 | We shoudl also capture other improtant state, like: |
||
36 | * MDRequest / Mutation |
||
37 | * Session |
||
38 | * LogSegments |
||
39 | |||
40 | Then we wire them up to admin/dev comamnds to dump cache and other in-memory state. |
||
41 | The final step to make this usable on large clusters is to make the Formatter interface stream based. Right now it looks like: |
||
42 | * create Formater |
||
43 | * dump to it; class accumulates result in memory |
||
44 | * flush to a bufferlist |
||
45 | * write bufferlist to final destination |
||
46 | |||
47 | Instead, it should be more like |
||
48 | * create Formatter |
||
49 | * specify the sink (bufferlist, fd, something). maybe make it an ostream, and make bufferlist work with that? |
||
50 | * write to it. |
||
51 | * at the very end call flush() (no arguments!) |
||
52 | |||
53 | h3. %{color:gold}Work items% |
||
54 | |||
55 | h3. Coding tasks |
||
56 | |||
57 | # mds: add dump methods to CInode, CDir, CDentry, Capability |
||
58 | # mds: add dump methods to Session, MDRequest, LogSegment |
||
59 | # admin socket dump commands |
||
60 | # tell dump commands (dump to a file) |
||
61 | # Formatter: refactor into a stream-based implementation for better memory efficiency |
||
62 | # make the admin socket protocol handle a streaming output of unknown length. |