Hi Jeff,
On 22/07/16 16:14, Jeff Darcy wrote:
I don't think we need any list traversal because notify sends it down
the graph.
Good point. I think we need to change that, BTW. Relying on
translators to propagate notifications has proven very fragile, as many
of those events are overloaded to mean very different things to
different translators (e.g. just being up vs. having quorum) with
different rules for when they should or should not be propagated. Going
forward, I think we can save ourselves a lot of headaches by treating
notification as an infrastructure responsibility, and changing
translators to use something else (e.g. IPC fops or upcalls) for their
internal needs.
I partially agree. I think gluster core should have more control about
event propagation, however some events, as they are currently used, need
to be controlled by the xlator in some way.
For example GF_EVENT_CHILD_UP cannot be immediately sent once the xlator
itself has been completely initialized because this would mean that
upper xlators could start sending requests. In the specific case of ec,
this is not good, because with a single child up, the volume is
completely inoperable. On the other side, waiting for all subvolumes to
be up (or down) is a waste of time if there's some problem because ec
can begin working with less bricks.
Maybe the infrastructure should include some way to receive specific
events from the xlatoes and use them to propagate events between xlators
when appropriate. This way the xlator is not responsible to propagate
any event, but to maintain informed the gluster core about its current
state.
Xavi
But that's a different issue. For now, just pushing one PARENT_DOWN
to the top of the graph should suffice.
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
