state model diagram

state model diagram

[Koleos Fuscus]

Hi,

I found a state model diagram in the page that explains peering
(http://ceph.com/docs/firefly/dev/peering/). The image cannot be
visualised correctly. I build the docs and could open the image in an
appropriate size using graphviz but still the layout is too complex
and messy.
I decided to do my own state model to collaborate in the understanding
of ceph. Actually, it helps me to measure my own understanding of the
system. Using the diagram facilitates the decision of modeling one
event or skip another. You can find the diagram here:
https://wiki.ceph.com/Development/Add_erasure_coding_to_the_durability_model/Technical_details_on_the_model

Please give me your comments.

koleosfuscus

________________________________________________________________
"My reply is: the software has no known bugs, therefore it has not
been updated."
Wietse Venema

Re: state model diagram

[Loic Dachary]

[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]


Hi koleofuscus,

I took a look at https://wiki.ceph.com/Development/Add_erasure_coding_to_the_durability_model/Technical_details_on_the_model and it makes sense to me. However I wonder why you would want to go into that level of detail ? Could you point me where you would encode such details events in the current code ?

Cheers

On 26/06/2014 02:29, Koleos Fuscus wrote:
> Hi,
> 
> I found a state model diagram in the page that explains peering
> (http://ceph.com/docs/firefly/dev/peering/). The image cannot be
> visualised correctly. I build the docs and could open the image in an
> appropriate size using graphviz but still the layout is too complex
> and messy.
> I decided to do my own state model to collaborate in the understanding
> of ceph. Actually, it helps me to measure my own understanding of the
> system. Using the diagram facilitates the decision of modeling one
> event or skip another. You can find the diagram here:
> https://wiki.ceph.com/Development/Add_erasure_coding_to_the_durability_model/Technical_details_on_the_model
> 
> Please give me your comments.
> 
> koleosfuscus
> 
> ________________________________________________________________
> "My reply is: the software has no known bugs, therefore it has not
> been updated."
> Wietse Venema
> 

-- 
Loïc Dachary, Artisan Logiciel Libre


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: state model diagram

[Sage Weil]

Hi Koleofuscus, Loic,

I see several minor inaccuracies on that diagram, but my main question 
(like Loic) is whether they are relevant for the reliability model.

For example, backfill and 'remap and get sync' are more or less equivalent 
(tho backfill is missing the 'delete stray replicas' state after); it make 
little difference from a durability perspective whether it is the primary 
or a replica that fails unless you are watching the messages go by.  And I 
think the exceptional cases (unfound objects) can be simplified.

sage


On Tue, 1 Jul 2014, Loic Dachary wrote:

> 
> Hi koleofuscus,
> 
> I took a look at 
> https://wiki.ceph.com/Development/Add_erasure_coding_to_the_durability_model/Technical_details_on_the_model 
> and it makes sense to me. However I wonder why you would want to go into 
> that level of detail ? Could you point me where you would encode such 
> details events in the current code ?
> 
> Cheers
> 
> On 26/06/2014 02:29, Koleos Fuscus wrote:
> > Hi,
> > 
> > I found a state model diagram in the page that explains peering
> > (http://ceph.com/docs/firefly/dev/peering/). The image cannot be
> > visualised correctly. I build the docs and could open the image in an
> > appropriate size using graphviz but still the layout is too complex
> > and messy.
> > I decided to do my own state model to collaborate in the understanding
> > of ceph. Actually, it helps me to measure my own understanding of the
> > system. Using the diagram facilitates the decision of modeling one
> > event or skip another. You can find the diagram here:
> > https://wiki.ceph.com/Development/Add_erasure_coding_to_the_durability_model/Technical_details_on_the_model
> > 
> > Please give me your comments.
> > 
> > koleosfuscus
> > 
> > ________________________________________________________________
> > "My reply is: the software has no known bugs, therefore it has not
> > been updated."
> > Wietse Venema
> > 
> 
> -- 
> Lo?c Dachary, Artisan Logiciel Libre
> 
> 

Re: state model diagram

[Koleos Fuscus]

Hello all,

Thanks for the comments. It is true, the state model has too many
details. I don’t see such level of detailed in the current code,
something that I fully agree. As the original author said, we need to
“assert only failure cases with statistically interesting
consequences”. But, I did a diagram for two reasons: 1) get an overall
idea of how and when the process related with detecting and repairing
errors are launched and 2) see if other reliability models may apply
to the ceph case.

Overall, I think the figure is much better than the diagram published
in http://ceph.com/docs/firefly/dev/peering/ that triggered me to do
sth about it. Initially, I was trying to understand the peering
process and all the things that happen when a OSD fails the peering.
In future, I would like to have a better version and maybe include it
in the paper.

Best

koleosfuscus

________________________________________________________________
"My reply is: the software has no known bugs, therefore it has not
been updated."
Wietse Venema


On Wed, Jul 2, 2014 at 9:28 PM, Sage Weil <sweil@redhat.com> wrote:
> Hi Koleofuscus, Loic,
>
> I see several minor inaccuracies on that diagram, but my main question
> (like Loic) is whether they are relevant for the reliability model.
>
> For example, backfill and 'remap and get sync' are more or less equivalent
> (tho backfill is missing the 'delete stray replicas' state after); it make
> little difference from a durability perspective whether it is the primary
> or a replica that fails unless you are watching the messages go by.  And I
> think the exceptional cases (unfound objects) can be simplified.
>
> sage
>
>
> On Tue, 1 Jul 2014, Loic Dachary wrote:
>
>>
>> Hi koleofuscus,
>>
>> I took a look at
>> https://wiki.ceph.com/Development/Add_erasure_coding_to_the_durability_model/Technical_details_on_the_model
>> and it makes sense to me. However I wonder why you would want to go into
>> that level of detail ? Could you point me where you would encode such
>> details events in the current code ?
>>
>> Cheers
>>
>> On 26/06/2014 02:29, Koleos Fuscus wrote:
>> > Hi,
>> >
>> > I found a state model diagram in the page that explains peering
>> > (http://ceph.com/docs/firefly/dev/peering/). The image cannot be
>> > visualised correctly. I build the docs and could open the image in an
>> > appropriate size using graphviz but still the layout is too complex
>> > and messy.
>> > I decided to do my own state model to collaborate in the understanding
>> > of ceph. Actually, it helps me to measure my own understanding of the
>> > system. Using the diagram facilitates the decision of modeling one
>> > event or skip another. You can find the diagram here:
>> > https://wiki.ceph.com/Development/Add_erasure_coding_to_the_durability_model/Technical_details_on_the_model
>> >
>> > Please give me your comments.
>> >
>> > koleosfuscus
>> >
>> > ________________________________________________________________
>> > "My reply is: the software has no known bugs, therefore it has not
>> > been updated."
>> > Wietse Venema
>> >
>>
>> --
>> Lo?c Dachary, Artisan Logiciel Libre
>>
>>
--
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