[Sheepdog] A question about sheepdog's beahvior ...

[Davide Casale]

Hi to all again,
some other questions :

3 machines with redundancy 2 .. which is the logic of the algorithm to 
redistribuite the blocks around the 3 machines ?
The machine with less disk space receives more data blocks than another 
one with a lot of more disk space ...

And what happens if one of the cluster machine arrives to have the disk 
full ? Sheepdog redistribuites the data blocks
upon the others or a data corruption happens?

Squid1 is a qcow2 machine (not compressed) of 514MB .. In the sheepdog 
disk it seems to be 1.2GB (2.4GB with the redundancy set to 2)..
Is there a way to calculate how much a qcow2 image increases in size 
inside sheepdog ?

thank you,
soon,
davide

root at kvm-sheeptest1:/var/lib/sheepdog# collie node info
Id      Size    Used    Use%
  0      291 GB  1.0 GB    0%
  1      220 GB  548 MB    0%
  2      13 GB   912 MB    6%

Total   524 GB  2.4 GB    0%, total virtual VDI Size    50 GB

root at kvm-sheeptest1:/var/lib/sheepdog# collie vdi list
   name        id    size    used  shared    creation time   vdi id
------------------------------------------------------------------
   Squid1       1   40 GB  1.2 GB  0.0 MB 2010-10-27 09:37    838f8
   Alice        1   10 GB  0.0 MB  0.0 MB 2010-10-27 09:41   15d167

root at kvm-sheeptest1:/var/lib/sheepdog# collie node list
   Idx   Node id (FNV-1a) - Host:Port
------------------------------------------------
   0     0314cd9ec329a0d7 - 192.168.6.205:7000
   1     2b593652a7240c41 - 192.168.7.224:7000
* 2     c1d1da18e6798a3a - 192.168.7.223:7000


On 27/10/2010 8.16, MORITA Kazutaka wrote:
> At Tue, 26 Oct 2010 12:39:06 +0200,
> Davide Casale wrote:
>> Hi to all,
>> I've installed Sheepdog Daemon, version 0.1.0 (with corosync 1.2.0 svn
>> rev. 2637) on ubuntu 10.04LTS..
>> The corosync.conf file is (for the useful part) :
>> ---
>> compatibility: whitetank
>> totem {
>>           version: 2
>>           secauth: off
>>           threads: 0
>>           token: 3000
>>           consensus: 5000
>>           interface {
>>                   ringnumber: 0
>>                   bindnetaddr: 192.168.7.x
>>                   mcastaddr: 226.94.1.1
>>                   mcastport: 5405
>>           }
>> }
>> ---
>> I've installed all on three machines with default redundancy (that's 3,
>> it's correct? I launch sheepdog with default /etc/init.d/sheepdog start)..
> Yes, it's default redundancy.
>
>> I've got 20GB of kvm virtual machines ..
>>
>> The questions are :
>>
>> - is it correct that if a single node crash (or I stop with "killall
>> sheep" the sheepdog processes) when I relaunch sheepdog ALL the data
>> are rebuilt from scratch from the other two nodes (each time it restarts
>> from zero bytes to arrive to 20GB) ?
>> I thought that only the changed blocks (4mb each) are resyncronized .... ??
> Yes, it's correct behavior.  Sheepdog cannot detect which objects are
> updated from the previous node membership change, so it is safe to
> receive all objects from the already joined nodes.  However, as you
> say, it's worth considering to optimize it.
>
>> - is it correct that when the syncronization is running on a node, all
>> the others are frozen (and also the kvm virtual machines are frozen)
>> until the syncronization is completed ?
> Yes.  Currently, if a virtual machine accesses to the object which is
> not placed on the right nodes (it could happen because of node
> membership changes), sheepdog stops the access until the object is
> moved to the right node.  But this behavior should be fixed as soon as
> possible, I think.
>
>> And perhaps this is a little bug:
>> if during the syncronization I launch on the node in syncronization the
>> command 'collie node info', the command remain in standby after
>> the first output.. if I stop it with CTRL+C, when the syncronization
>> ended one of the sheep process crash and if I relaunch sheepdog the
>> sycnronization starts again from the beginning (from zero bytes) ...
>>
> The reason 'collie node info' sleeps is same with above.  The problem
> that sheep crashes would be fixed by the following patch.  Thanks for
> your feedback.
>
>
> =
> From: MORITA Kazutaka<morita.kazutaka at lab.ntt.co.jp>
> Subject: [PATCH] sheep: call free_request() after decrementing reference counters
>
> We cannot call free_req() here because client_decref() accesses
> req->ci.
>
> Signed-off-by: MORITA Kazutaka<morita.kazutaka at lab.ntt.co.jp>
> ---
>   sheep/sdnet.c |    7 ++++++-
>   1 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/sheep/sdnet.c b/sheep/sdnet.c
> index 9ad0bc7..6d7e7a3 100644
> --- a/sheep/sdnet.c
> +++ b/sheep/sdnet.c
> @@ -271,12 +271,17 @@ static void free_request(struct request *req)
>
>   static void req_done(struct request *req)
>   {
> +	int dead = 0;
> +
>   	list_add(&req->r_wlist,&req->ci->done_reqs);
>   	if (conn_tx_on(&req->ci->conn)) {
>   		dprintf("connection seems to be dead\n");
> -		free_request(req);
> +		dead = 1;
>   	}
>   	client_decref(req->ci);
> +
> +	if (dead)
> +		free_request(req);
>   }
>
>   static void init_rx_hdr(struct client_info *ci)


-- 

----------------------------------
DAVIDE CASALE
Security Engineer
mailto:casale at shorr-kan.com

SHORR KAN IT ENGINEERING Srl
www.shorr-kan.com
Via Sestriere 28/a
10141 Torino
Phone:  +39 011 382 8358
Fax:    +39 011 384 2028
----------------------------------