[Sheepdog] [PATCH 1/2] sheep: sheep: handle node change event first
MORITA Kazutaka
morita.kazutaka at gmail.com
Sun Apr 1 13:12:28 CEST 2012
At Sun, 01 Apr 2012 18:31:24 +0800,
Liu Yuan wrote:
>
> On 04/01/2012 04:47 PM, MORITA Kazutaka wrote:
>
> >> > Let's leave aside IO req that are just queued, not issued.
> >> >
> >> > Even with separate queues, seems that we need to wait for completion of
> >> > infly IOs. No?
> > Yes.
> >
>
>
> So either way, we need to wait for infly io. This brings problem, since
> queuing is processed in main thread.
Yes, but succeeding membership messages can be processed immediately
because we can skip I/O requests in cpg_event_siblings, no?
>
> >> >
> >> > So one queue with higher priority placement of notify & confchg event,
> >> > we could have a working solution.
> > Yes, I guess it will work. I thought it is simpler to use two queues
> > than traversing one queue to find the proper placement, though.
>
>
> Placement is very simple, that is why I used a single queue, just
> inserting it at head, since if there is no infly IO hanging around, we
> are guaranteed that the event in the head of the queue will be processed
> immediately.
But some nodes may have outstanding I/Os but the others may not...
I really don't understand how all nodes process events in the same
order if we add them to the head of the FIFO queue. Some nodes can
process messages in the delivered order, but the other ones can do
them in the reverse order if there are pending messages. I think it
is not good at all to process messages in the different order from the
multicasted order.
Maybe, I'm missing some points. If it is not difficult to implement
those, I'd like to see the code.
Thanks,
Kazutaka
More information about the sheepdog
mailing list