From: Joao Eduardo Luis <joao@suse.de>
To: "Chen, Xiaoxi" <xiaoxi.chen@intel.com>
Cc: "ceph-devel@vger.kernel.org" <ceph-devel@vger.kernel.org>
Subject: Re: What's the difference between Paxos::trim() and PaxosService::trim?
Date: Fri, 27 Nov 2015 11:20:08 +0000 [thread overview]
Message-ID: <56583C68.6050801@suse.de> (raw)
In-Reply-To: <6F3FA899187F0043BA1827A69DA2F7CC03653DD1@shsmsx102.ccr.corp.intel.com>
Hi Xiaoxi,
cc-ing ceph-devel for posterity ;)
On 11/27/2015 08:25 AM, Chen, Xiaoxi wrote:
> Hi joao,
>
> I am a bit confuse about the difference between in
> Paxos::trim() and PaxosService::trim? Seems they did same work basically?
In essence, both have the same purpose: remove no longer needed versions
from the monitor store. They do, however, focus on different kinds of
versions.
The main difference is the way the Paxos class and PaxosService access
the store.
PaxosService provides an abstraction to services (e.g., OSDService) such
that each service, in a way, doesn't have to care much how their keys
are named. PaxosService handles this by suffixing each key with the
service's name (e.g., osdmap). Also, services tend to keep both
incremental and full versions, and the PaxosService class is also aware
of this.
Hence, PaxosService::trim() removes both incremental and full versions
when the service prescribes a trim, while making sure that only versions
related to that service are actually removed -- upon trim, the
OSDMonitor will not remove MonmapMonitor's versions.
On the other hand, Paxos::trim() deals solely with paxos versions.
One should also take into account that each service may have different
criteria on when to trim -- and PaxosService's abstraction takes that
into account -- while the Paxos class' criteria is pretty
straightforward: keep a minimum of N versions and a maximum of M.
Then you have PaxosService::maybe_trim(), where most of the logic on
deciding "when to trim" is located, even though ascertaining the bounds
are delegated to the services themselves. Again, given PaxosService is
an abstraction for the various services, you also get a bunch of logic
related to the nuances of removing versions from a paxos service, such
as allowing each service to trim additional stuff beyond the incremental
and full versions.
In the end, maybe we could find a generic function that could serve both
the Paxos class and PaxosServices, but these are both simple enough that
I don't think that is warranted. I have the feeling we would always end
up with at least one additional function (the generic one) and would
maintain most of the logic on both Paxos::trim() and
PaxosService::trim() in place anyway, and I don't think that's worth it.
Hope this helps clarifying things a bit.
-Joao
parent reply other threads:[~2015-11-27 11:20 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <6F3FA899187F0043BA1827A69DA2F7CC03653DD1@shsmsx102.ccr.corp.intel.com>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56583C68.6050801@suse.de \
--to=joao@suse.de \
--cc=ceph-devel@vger.kernel.org \
--cc=xiaoxi.chen@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.