Feature #3626
closedmds: debug mode to generate traceless replies to clients
0%
Updated by Sage Weil over 11 years ago
- Translation missing: en.field_position deleted (
1) - Translation missing: en.field_position set to 17
Updated by Sage Weil over 11 years ago
- Translation missing: en.field_position deleted (
20) - Translation missing: en.field_position set to 2
Updated by Sage Weil over 11 years ago
- Translation missing: en.field_position deleted (
5) - Translation missing: en.field_position set to 4
Updated by Greg Farnum over 11 years ago
Am I reading it correctly that this is just going to be doing the config and wrapper work to not call set_trace() in Server::set_trace_dist()?
Updated by Sage Weil over 11 years ago
- Status changed from New to 12
Greg Farnum wrote:
Am I reading it correctly that this is just going to be doing the config and wrapper work to not call set_trace() in Server::set_trace_dist()?
I think so, although there may be more to it than that. We need things from the client to look as much like they would when requests are replayed, but without screwing up the MDS's notion of shared state. Hopefully no set_trace_dist() is enough.
Updated by Greg Farnum over 11 years ago
Hurray, it is. Nobody except the client looks at the trace_bl and setting that is the only thing set_trace() does. Excluding that while still doing all the work to build the trace on the MDS should be sufficient!
Updated by Sage Weil over 11 years ago
Greg Farnum wrote:
Hurray, it is. Nobody except the client looks at the trace_bl and setting that is the only thing set_trace() does. Excluding that while still doing all the work to build the trace on the MDS should be sufficient!
Er, we don't want to do the work to build the trace (and then throw it out) because that screws up the client/mds shared state (cap seq #'s and so forth). This is the problem with the old code in the kclient that just ignored that part of the reply. But IIRC not calling set_trace_dist(), as you said, should do the right thing (i.e. not do the work, and not send it).
Updated by Greg Farnum over 11 years ago
Hmm, okay. I wasn't real clear on the previous bugs so I'll need to look at it more if I end up taking this, but sounds good to me.
Updated by Sage Weil over 11 years ago
- Translation missing: en.field_story_points changed from 2 to 3
- Translation missing: en.field_position deleted (
9) - Translation missing: en.field_position set to 4
Updated by Sage Weil about 11 years ago
- Target version set to v0.58
- Translation missing: en.field_position deleted (
7) - Translation missing: en.field_position set to 5
Updated by Greg Farnum about 11 years ago
- Status changed from 12 to In Progress
Server::set_trace_dist() sets several things on the reply:
*snapbl
*head.is_dentry
*head.is_target
*trace_bl
However, none of these are accessed outside of Client::insert_trace(), and they're only looked at if trace_bl is non-empty. So from the client's perspective, just skipping set_trace_dist is fine.
Happily, it also appears that nothing else is going to do anything weird with the shared state that simply skipping set_trace_dist() will drop on the floor — it calls Locker::issue_client_lease() directly, etc.
That means that we can just have the MDS skip adding the trace on update operations (some configurable percentage of the time), and that should be pretty simple and satisfy this ticket. Hurray!
Updated by Greg Farnum about 11 years ago
- Status changed from In Progress to Fix Under Review
wip-4036 (commit:4ebba50a15584c89e0c5e4c6e48618055ceb96d8). Testing it now with pjd on a vstart cluster with no traceless replies, and all traceless replies (the latter crashes pretty quickly). Assuming my addition of a dout() won't break it. ;)
Updated by Greg Farnum about 11 years ago
Merged into master in commit:08b82b3ef6b43283e35fd4e56eb5c78651345bea.
Updated by Greg Farnum about 11 years ago
- Status changed from Fix Under Review to Resolved