logger: correct crash_handler output

'pid' is always 0 in logger process. So it is useless to
output it.

- fix logger pid output.

Signed-off-by: Liu Yuan <tailai.ly@taobao.com>
fix a bug of copies calculation in delete_one()

It tries to compare the nr_copies with inode->nr_copies,
but the inode has just been allocated, the nr_copies may
be zero or something random

Signed-off-by: levin li <xingke.lwp@taobao.com>
Signed-off-by: Liu Yuan <tailai.ly@taobao.com>
Make connection information more readable

Add ipstr and port in connection structure, and fill these values
in create_client(). We can dprintf them when we need to show us where
the client connection comes from.

To help us debuging, I dprintf these info in client_rx_handler() and
destroy_client().

Signed-off-by: Yunkai Zhang <qiushu.zyk@taobao.com>
Signed-off-by: Liu Yuan <tailai.ly@taobao.com>
object_cache: fix a race condition

create_cache_object() need to get a lock to avoid race with
object_cache_rw().

This is to address below bug in the log:
Apr 28 17:48:12 do_io_request(931) 2, 47c33f00003f80 , 1
Apr 28 17:48:12 object_cache_rw(321) 00003f80, len 4096, off 1396736
Apr 28 17:48:12 client_rx_handler(427) HEAD, fd:280
Apr 28 17:48:12 client_rx_handler(432) DATA_INIT, fd:280
Apr 28 17:48:12 client_rx_handler(470) END, fd:280
Apr 28 17:48:12 queue_request(275) 2
Apr 28 17:48:12 do_io_request(931) 2, b1f0b000003f9b , 1
Apr 28 17:48:12 object_cache_pull(423) [local] 00003f9b
Apr 28 17:48:12 object_cache_pull(423) [local] 00003f9b
Apr 28 17:48:12 create_cache_object(352) 00003f9b already created
Apr 28 17:48:12 object_cache_rw(321) 00003f9b, len 16384, off 2940928
Apr 28 17:48:12 read_cache_object(307) size =0; count= 16384
Apr 28 17:48:12 do_io_request(956) failed: 2, b1f0b000003f9b , 1, 3
Apr 28 17:48:12 io_op_done(151) leaving sheepdog cluster
corosync: fix cluster hang

Consider two nodes cluster, A is the master and B is going
to join.
		A: I'm the master
B: send_join_msg
		A: crached before sending join_response
B: blocked for ever

The fix is let B go as far as possible, where B can find himself
become the master.

1) path the code to simulate the problem:

@@ -280,6 +280,7 @@ static int __corosync_dispatch_one(struct
corosync_event *cevent)
        enum cluster_join_result res;
        struct sd_node entries[SD_MAX_NODES];
        int idx;
+       static int i;

        switch (cevent->type) {
        case COROSYNC_EVENT_TYPE_JOIN:
@@ -300,6 +301,12 @@ static int __corosync_dispatch_one(struct
corosync_event *cevent)
                        if (res == CJ_RES_MASTER_TRANSFER)
                                nr_cpg_nodes = 0;

+                       i++;
+                       if (i == 2) {
+                               dprintf("%d\n", i);
+                               panic("Okay, I am forced out\n");
+                       }
+
                        send_message(COROSYNC_MSG_TYPE_JOIN_RESPONSE, res,
                                     &cevent->sender, cpg_nodes,
nr_cpg_nodes,
                                     cevent->msg, cevent->msg_len);

2) run the following script:
for i in 0 1 2; do sheep/sheep -a -d /home/tailai.ly/sheepdog/store/$i -z $i -p 700$i;sleep 1;done

Now we can handle this very case nicely, that mastership is transferred from 0 to 1, and from 1 to 2
dispite of master is crashed before sending response.

But, we can't handle below script yet:
for i in 0 ; do sheep/sheep -a -d /home/tailai.ly/sheepdog/store/$i -z $i -p 700$i;sleep 1;done
for i in 1 2; do sheep/sheep -a -d /home/tailai.ly/sheepdog/store/$i -z $i -p 700$i;done #no sleep

Question is:
 Do we really need to handle above artificial scenario?