From: Joao Eduardo Luis <jecluis@gmail.com>
To: Sage Weil <sage@newdream.net>, kefu chai <tchaikov@gmail.com>
Cc: "ceph-devel@vger.kernel.org" <ceph-devel@vger.kernel.org>
Subject: Re: adding "{mds,mon} metadata" asok command
Date: Mon, 23 Mar 2015 10:04:43 +0000 [thread overview]
Message-ID: <550FE53B.9050407@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1503200628150.7043@cobra.newdream.net>
Sorry for the latency.
On 03/20/2015 01:30 PM, Sage Weil wrote:
> On Fri, 20 Mar 2015, kefu chai wrote:
>> on the mon side, i will apply the same approach to MMonJoin and
>> MonmapMonitor, but with another prefix when putting encoding metadata
>> into transaction.
>
> The MMonJoin is only used when expanding the cluster, i.e. when first
> adding the new monitor during cluster configuration time.
>
>> @joao, IIRC, you were suggesting me to add another paxos service for
>> this purpose but is it feasible to put this data into MMonJoin and
>> persist it into the paxos service's storage?
>>
>> any suggestion or comments would be appreciated. if no objections, i
>> will be on it.
>
> Instead, I suggest having each mon generate the metadata during startup.
> Then, somewhere during bootstrap(), compare the stored metadata (they all
> have a copy of the mon data set) with the actual metadata, and if it
> varies send a new message (MMonUpdateMetadata?) to the leader requesting a
> change.
I agree. And I don't think we need a new service for this, and I also
don't think we need to write stuff to the store. We can generate this
information when the monitor hits 'bootstrap()' and share it with the
rest of the quorum once an election finishes, and always keep it in
memory (unless there's some information that needs to be persisted, but
I was under the impression that was not the case).
This, btw, is what mon/DataHealthService.cc does, but you should be able
to avoid stuffing this into a service or creating a new service. The
timecheck stuff in the monitor also works a bit like this -- take a look
at those if you need a guideline.
Cheers!
-Joao
>
> Joao, what do you think?
>
> sage
>
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Joao Eduardo Luis | github.com/jecluis
next prev parent reply other threads:[~2015-03-23 10:04 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-20 5:39 adding "{mds,mon} metadata" asok command kefu chai
2015-03-20 11:43 ` John Spray
[not found] ` <CAJE9aOPK6Qge8BNvB0na2-Y_12THB2aSmk-wvpPytAwcjonMGQ@mail.gmail.com>
2015-03-20 15:58 ` Fwd: " kefu chai
2015-03-20 13:30 ` Sage Weil
2015-03-20 16:04 ` kefu chai
2015-03-23 10:04 ` Joao Eduardo Luis [this message]
2015-03-23 10:35 ` John Spray
2015-03-23 13:58 ` Sage Weil
2015-03-24 10:11 ` Joao Eduardo Luis
2015-03-24 10:20 ` John Spray
2015-03-25 18:18 ` kefu chai
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=550FE53B.9050407@gmail.com \
--to=jecluis@gmail.com \
--cc=ceph-devel@vger.kernel.org \
--cc=sage@newdream.net \
--cc=tchaikov@gmail.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.