| 10600 | } |
| 10601 | |
| 10602 | bool OSDMonitor::prepare_command_impl(MonOpRequestRef op, |
| 10603 | const cmdmap_t& cmdmap) |
| 10604 | { |
| 10605 | op->mark_osdmon_event(__func__); |
| 10606 | auto m = op->get_req<MMonCommand>(); |
| 10607 | stringstream ss; |
| 10608 | string rs; |
| 10609 | bufferlist rdata; |
| 10610 | int err = 0; |
| 10611 | |
| 10612 | string format = cmd_getval_or<string>(cmdmap, "format", "plain"); |
| 10613 | boost::scoped_ptr<Formatter> f(Formatter::create(format)); |
| 10614 | |
| 10615 | string prefix; |
| 10616 | cmd_getval(cmdmap, "prefix", prefix); |
| 10617 | |
| 10618 | int64_t osdid; |
| 10619 | string osd_name; |
| 10620 | bool osdid_present = false; |
| 10621 | if (prefix != "osd pg-temp" && |
| 10622 | prefix != "osd pg-upmap" && |
| 10623 | prefix != "osd pg-upmap-items") { // avoid commands with non-int id arg |
| 10624 | osdid_present = cmd_getval(cmdmap, "id", osdid); |
| 10625 | } |
| 10626 | if (osdid_present) { |
| 10627 | ostringstream oss; |
| 10628 | oss << "osd." << osdid; |
| 10629 | osd_name = oss.str(); |
| 10630 | } |
| 10631 | |
| 10632 | // Even if there's a pending state with changes that could affect |
| 10633 | // a command, considering that said state isn't yet committed, we |
| 10634 | // just don't care about those changes if the command currently being |
| 10635 | // handled acts as a no-op against the current committed state. |
| 10636 | // In a nutshell, we assume this command happens *before*. |
| 10637 | // |
| 10638 | // Let me make this clearer: |
| 10639 | // |
| 10640 | // - If we have only one client, and that client issues some |
| 10641 | // operation that would conflict with this operation but is |
| 10642 | // still on the pending state, then we would be sure that said |
| 10643 | // operation wouldn't have returned yet, so the client wouldn't |
| 10644 | // issue this operation (unless the client didn't wait for the |
| 10645 | // operation to finish, and that would be the client's own fault). |
| 10646 | // |
| 10647 | // - If we have more than one client, each client will observe |
| 10648 | // whatever is the state at the moment of the commit. So, if we |
| 10649 | // have two clients, one issuing an unlink and another issuing a |
| 10650 | // link, and if the link happens while the unlink is still on the |
| 10651 | // pending state, from the link's point-of-view this is a no-op. |
| 10652 | // If different clients are issuing conflicting operations and |
| 10653 | // they care about that, then the clients should make sure they |
| 10654 | // enforce some kind of concurrency mechanism -- from our |
| 10655 | // perspective that's what Douglas Adams would call an SEP. |
| 10656 | // |
| 10657 | // This should be used as a general guideline for most commands handled |
| 10658 | // in this function. Adapt as you see fit, but please bear in mind that |
| 10659 | // this is the expected behavior. |
nothing calls this directly
no test coverage detected