fix a bug in rx() when read() returns 0 but connection is not marked as closed.

if read() returns 0，it means connection closed, but previous
read() may set errno to EAGAIN, in which case rx() would just
return 0 without set connection state as C_IO_CLOSED

Signed-off-by: levin li <xingke.lwp@taobao.com>
Signed-off-by: Liu Yuan <tailai.ly@taobao.com>
collie: add an operation to show nodes in recovery

It's useful to show nodes in recovery when we debuging
or maintaining the cluster, many times we want to know
which nodes are in recovery, before this, we check the
logs to find out whether the cluster has ended recovery,
but with this patch, it's easier.

usage:

#collie node recovery

output:

Nodes In Recovery:
 Id   Host:Port         V-Nodes       Zone
  4   127.0.0.1:7006     	64          6
  5   127.0.0.1:7007      	64          7
  8   127.0.0.1:7010      	64         10
  9   127.0.0.1:7011      	64         11
 10   127.0.0.1:7012      	64         12

Signed-off-by: levin li <xingke.lwp@taobao.com>
Signed-off-by: Liu Yuan <tailai.ly@taobao.com>
logger: improve death messages

Make the fact more clear that a SIGHUP to the logger means that the
sheep daemon died a horrible dead.  Also improve the log messag for
a logger death a little, and rename log_sigexit so the name describes
its function better.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: MORITA Kazutaka <morita.kazutaka@lab.ntt.co.jp>
logger: cleanup dolog

Remove the write only ts variable, move ops into the minimal required scope
and break lines after 80 characters.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: MORITA Kazutaka <morita.kazutaka@lab.ntt.co.jp>
sheep: do not automatically log to syslog if run in foreground

Add a new --stdout option to explicitly chose logging to stdout instead of
automatically selecting it when running in foreground.  Many daemons like
upstart, supervisord or systemd prefer programs to not daemonize, but don't
nessecarily handle logging to stdout very well.  To support these better
allow running in foreground while still logging to syslog.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: MORITA Kazutaka <morita.kazutaka@lab.ntt.co.jp>
sheep: remove cdrv_handlers and check_join_cb

Instead of obscuring the callbacks into sheepdog from the cluster drivers
by various means of callbacks just call them directly like you would do in
normal C code.  The block_cb callback to the notify routine is left for now
as that area needs broader attention later.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: MORITA Kazutaka <morita.kazutaka@lab.ntt.co.jp>
sheep: fix epoll_wait infinite loop

Add code to handle EPOLLERR and EPOLLHUP events in client_handler,
otherwise epoll_wait would run into infinite loop when these events
occur.

Signed-off-by: Yunkai Zhang <qiushu.zyk@taobao.com>
Signed-off-by: MORITA Kazutaka <morita.kazutaka@lab.ntt.co.jp>
deleting data objects of a vdi before deleting the inode

Currently, when deleting a vdi, sheep firstly clears the name
in the vdi inode to mark it as deleted, then try to delete the
data objects, there's a problem, if deleting one or more data
objects fails, we could never delete the object any more, because
the inode has been deleted.

Now I exchange the order of deleting inode and data objects, if
deleting some data object successes, we clear the the correlative
flag in inode->data_vdi_id[], orelse we set the dw->delete_error to
tell that an error occurs in the deletion work.

In delete_one_done(), if dw->delete_error is true, we set inode->vdi_size
to 0 to show this vdi has been deleted, but fail to delete some of
its objects, then we can try to delete the vdi again.

Signed-off-by: levin li <xingke.lwp@taobao.com>
always delete data objects when deleting an cloned vdi

When deleting a cloned vdi, sheep find the root vdi and then
traverse the vdi chain(such as base --> snapshot --> clone) to
check wheter there's an undeleted vdi in the chain, if some vdi
in the chain isn't deleted, sheep just mark the cloned vdi as
deleted by clear its vdi name.

But in fact a cloned vdi may created its own objects by copy-on-write,
these objects can be deleted when deleting the vdi, so we make
the cloned vdi to be deleted as the root vdi, then we can deleting
its data objects, in delete_one() we check whether the object belongs
to itself to determine whether to delete the object.

Signed-off-by: levin li <xingke.lwp@taobao.com>