Thanks, sir:-)
At 2016-10-24 18:42:53, "Sage Weil" <sage@xxxxxxxxxxxx> wrote:
>On Mon, 24 Oct 2016, xxhdx1985126 wrote:
>> Thanks, sir:-) I got it. I'll try to understand the "peering" part of
>> code.:-)
>>
>> By the way, please allow me to ask just one more question:-)
>> Under what circumstance will the OSDMap mark a newly added osd "UP"? Or, in
>> other words, how does the OSDMap judge whether or not an booting osd has
>> finished the 'booting' sequence and should be mark "UP"?
>>
>> Thank you very much, sir:-)
>
>Once the starting OSD has fetched all of the OSDMaps from the monitor (to
>within a few epochs at least), it will send an MOSDBoot message asking the
>monitor to mark it UP.
>
>See OSD::start_boot() to follow the the full sequence!
>
>sage
>
>
> >
>>
>>
>>
>> At 2016-10-24 18:06:45, "Sage Weil" <sage@xxxxxxxxxxxx> wrote:
>> >On Mon, 24 Oct 2016, xxhdx1985126 wrote:
>> >> Hi, everyone.
>> >>
>> >>
>> >> I'm trying to read the source code that boots an OSD instance, and I find
>> something really overwhelms me.
>> >> In the OSD::init() method, it read the OSDSuperblock by calling OSD::read
>> _superblock(), and the it tried to get the "current" map : "osdmap = get_map
>> (superblock.current_epoch)". Then OSD uses this osdmap to calculate the acti
>> ng and up set of each pg.
>> >> I really don't understand this! Since the OSDSuperblock is read from the
>> disk, the content of the superblock.current_epoch must be an old epoch which
>> is recorded by the last OSD instance that run on the ceph osd's directory.
>> Why use an old "current_epoch" to calculate the acting and up set of each pg
>> ?
>> >
>> >Yes. load_pgs() instantiates all of the PGs, populates the current (==
>> >current_epoch) up and acting vectors, and triggers a loaded event to help
>> >get everything in-memory initialized.
>> >
>> >Then, during the 'booting' sequence, we request the latest map from the
>> >monitor, and respond to any changes in the OSDMap--everything that
>> >happened while the OSD was down, and eventually the OSDmap that indicates
>> >the OSD is now up. At that point it can start doing useful work. Look for
>> >the AdvMap and ActMap state events.
>> >
>> >This process of responding to changes to the OSDMap and synchronizing with
>> >other OSDs in collectively called "peering" and is one of the more
>> >difficult areas of the code to understand. :/
>> >
>> >sage
>>
>>
>>
>>
>>
>>
��.n��������+%������w��{.n����z��u���ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
