[sheepdog] [PATCH v2 4/4] cluster driver: handle pending block/notify event during reconnect

[MORITA Kazutaka]

At Tue, 9 Jul 2013 10:35:50 +0800,
Kai Zhang wrote:
> 
> On Jul 9, 2013, at 8:46 AM, MORITA Kazutaka <morita.kazutaka at gmail.com> wrote:
> 
> > At Sun,  7 Jul 2013 21:20:51 -0700,
> > Kai Zhang wrote:
> >> 
> >> Current implementation of reconnection doesn't handle pending block/notify
> >> event.
> >> 
> >> It is easy to handle notify event by sending it again.
> >> 
> >> However, it is a little bit complex for block event.
> >> This is because a block event need 4 steps.
> >> 1. in queue_cluster_request(), send block event by sys->cdrv->block(), and
> >>  add to pending_block_list.
> >> 2. in sd_block_handler(), queue the event to work queue of 'block' thread.
> >> 3. in cluster_op_done(), send unblock event by sys->cdrv->unblock().
> >> 4. in sd_notify_handler(), remove it from pending_block_list.
> >> 
> >> And step 1 and 3 contains broadcast operations.
> >> So we have to know which step has been done for a pending block event.
> >> 
> >> If step 1 has been done, we can re-queue it simply. (Any block event which sent
> >> by this node have been removed due to the leave event)
> >> If step 2 has been done, the event is handling by another thread. We have to mark
> >> it as 'drop' so that it will be dropped when cluster_op_done() is called later.
> >> if step 3 has been done, we should call sd_notify_handler() manually to finish
> >> it.
> >> 
> >> Signed-off-by: Kai Zhang <kyle at zelin.io>
> >> ---
> >> sheep/group.c      |   69 ++++++++++++++++++++++++++++++++++++++++++++++++++--
> >> sheep/sheep_priv.h |    8 ++++++
> >> 2 files changed, 75 insertions(+), 2 deletions(-)
> >> 
> >> diff --git a/sheep/group.c b/sheep/group.c
> >> index 2fa4091..1a549de 100644
> >> --- a/sheep/group.c
> >> +++ b/sheep/group.c
> >> @@ -251,6 +251,9 @@ static void cluster_op_done(struct work *work)
> >> 	struct vdi_op_message *msg;
> >> 	size_t size;
> >> 
> >> +	if (req->status == REQUEST_DROPPED)
> > 
> > I think adding sd_dprintf here would help us to debug.
> > 
> 
> We already have a sd_dprintf when we mark it as REQUEST_DROPPED.
> Do you think we should add one more here?

Looks unnecessary.  Please ignore my comment.

Thanks,

Kazutaka