Add Debian packaging
Merge commit 'v0.2.4'
Don't install init.d script
Document changes and release 0.2.4-1
Merge /home/david/hg/public/sheepdog
Merge commit 'v0.3.0'

Debian release 0.2.4-1
prepare debian version 0.3.0-1
release 0.3.0 and packaging updates

- update to policy 3.9.3
- add bash_completion
- update and simplify debian/rules
remove annoying *.orig and *.rej for 'make clean'

Signed-off-by: Liu Yuan <tailai.ly@taobao.com>
collie: allow explicit read sizes that are not a multiple of 512

Collie vdi read already does can handle read sizes smaller than a block,
which is used when reading data to stdout without an explicit size argument.
Also allow using this code when an explicit size argument is given.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Liu Yuan <tailai.ly@taobao.com>
fix a bug in the binary search in get_vnode_pos()

Consider the corner case that id is less than the id
of the first entry in entry list.

Signed-off-by: levin li <xingke.lwp@taobao.com>
Signed-off-by: Liu Yuan <tailai.ly@taobao.com>
add fls, fls64 operation for bit manipulation

Signed-off-by: Liu Yuan <tailai.ly@taobao.com>
object cache: use bitops for bits manipulation.

Signed-off-by: Liu Yuan <tailai.ly@taobao.com>
define constant for uint64 decimal string representation

Signed-off-by: Sebastian Wiedenroth <wiedi@frubar.net>
Signed-off-by: Liu Yuan <tailai.ly@taobao.com>
sheep: call do_cluster_request from the main thread

There are two problems with calling do_cluster_request from a work queue:

1) sys->pending_list is expected to only be used from the main thread and
   does not have any locking
2) the ->notify cluster driver metho is expected to be called from the
   main thread

Simplify call do_cluster_request directly from process_request_queue instead
of offloading it to a workqueue to fix this, and document the assumptions
in the code.

Based on an earlier patch from Yunkai Zhang <qiushu.zyk@taobao.com>.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Liu Yuan <tailai.ly@taobao.com>
sheep: delete useless get_vdi_bitmap_from_sd_list()

In __sd_join(), get_vdi_bitmap_from_sd_list() do a lot of duplicated
works with following for loop as w->member_list contains all nodes in
sys->nodes.

So we can drop get_vdi_bitmap_from_sd_list() safely, it can make
__sd_join() looks more cleanly.

Signed-off-by: Yunkai Zhang <qiushu.zyk@taobao.com>
Signed-off-by: Liu Yuan <tailai.ly@taobao.com>
sheep: handle master crashing before sending join request

This patch fixes one of the cases described by Huxinwei and Liu Yuan where
sheepdog fails to elect a master. A longer description is in the patch.

A problem arises if a node joins the cluster and generates a confchg event,
then crashes or leaves without sending a join request and receiving a join
response. The second node to join never becomes master, and the entire cluster
hangs.

This patch allows a node to detect whether it should promote itself to master
after an arbitrary confchg event. Every node except the master creates a
blocked JOIN event for every node that joined after itself, therefore the
master is the node which has a JOIN event for every node in the members list.

Signed-off-by: Shevek <shevek@anarres.org>
Signed-off-by: Liu Yuan <tailai.ly@taobao.com>
traverse the VDI tree before delete cloned VDI

Even if the VDI is a cloned VDI (not the VDI just created
by 'clone' operation, but the cloned VDI on the leaf node
of the VDI tree), we also should traverse the vdi tree from
the root VDI.

But if there's a VDI not deleted in the tree path, and the
VDI to delete is a cloned VDI, we should delete it's data
objects so as to save disk space. If all the VDIs have been
deleted in the tree path, then we traverse the path to delete
all the objects of the VDIs.

I'd like to explain again why we need to deleted the objects
created by copy-on-write when we try to delete a cloned VDI,
in the old logic, objects of cloned VDI can only be deleted
after all the VDI in the tree path has been deleted, but there's
a problem, we may clone many VDIs from one snapshot, and these
VDIs can be deleted frequently, but we may always not delete the
snapshot VDI, so in this case, objects of cloned VDI would
always stay in the disk, as we know, they're already useless
and should be deleted, and waste too much disk space, but we can
only make it deleted after all the VDI in the tree path, including
the snapshot VDI have beed deleted, it's really not good.

Signed-off-by: levin li <xingke.lwp@taobao.com>
Signed-off-by: Liu Yuan <tailai.ly@taobao.com>
fix a bug of deleting base vdi fail

Take a view of the following snapshot tree:

base vdi --> snapshot vdi --> cloned vdi

when cloned vdi has its own data objects created by copy-on-write,
we firstly delete the cloned VDI, then delete the base VDI, at last
we delete snapshot VDI, the the snapshot VDI would delete fail in this
case because in the old code, I try to delete all the VDIs from the
VDI tree, but the base VDI and the cloned VDI have beed deleted,
and it causes an error which finally cause snapshot VDI delete fail.

This patch is another version of my previous one which is here:
http://lists.wpkg.org/pipermail/sheepdog/2012-May/003332.html

I simplely reset the delete_error flag, as Kazutaka mentions, it's
not good to do this, but we should never try to delete the VDIs
already deleted again, so I mark an VDI as deeply deleted by clearing
its name and size, which means the VDI and it data objects have already
been deleted, then in the next deletion work, we can just ignore these
VDIs. If the data objects haven't been deleted, then we just clear its
name to mark it as deleted, next time, we can try to delete its data
objects.

Signed-off-by: levin li <xingke.lwp@taobao.com>
Signed-off-by: Liu Yuan <tailai.ly@taobao.com>
sheep: read cached data if it exists in read_object()

Signed-off-by: MORITA Kazutaka <morita.kazutaka@lab.ntt.co.jp>