[Sheepdog] sheepdog image created but sheperd does not show it

[MORITA Kazutaka]

Piavlo wrote:
> MORITA Kazutaka wrote:
>> Yes. Sheepdog uses a hash function to map nodes to a consistent hash
>> ring, so if the number of nodes is small, objects are not well
>> distributed. 
>  If there are say 10 storage nodes , most prople would probably want to 
> use --copies=2 or --copies=3
> not --copies=10. Since single VM  image is distributed among all 10
> nodes with --copies=2 - it is enough for
> two nodes out of 10 to go offline and the VM won't be available anymore.
> If one storage node goes offline - does sheepdog automatically
> replicates the data object that the failed node had to other nodes
> so that  there are always exactly --copies= of each sheepdog object in
> the active set of storage nodes?

Currently, not supported yet. But it will be supported soon.

>> I think sheepdog should take different approach to map
>> nodes to the ring for better balancing.
>>   
> Maybe some ideas from elliptic network can be implemented.
> It seems for me like a good idea just to take the elliptics project asis
> and integrate it with kvm.

Using other distributed object storage may be a choice.
But about free space balancing, changing node id corresponding to its own
free space is simpler approach and would work well, I think.

>> Each disk image is divided into 4 MB objects, and lower 18 bits in the
>> file name (block number) is a index of the objects.
>>
>> In your case,
>>  - first 4 MB (0 ~ 4 MB) is allocated as the object 40001
>>  - the next 4 MB (4 MB ~ 8 MB) is not allocated
>>   
> So why exactly these next 4MB are not allocated?

It is because your virtual machine have not written any data to the range.
If you run the following command on the VM, the object 40002 will be created.

dd if=/dev/zero of=/dev/sdb seek=1 bs=4M count=1
  (/dev/sdb is a virtual block device of sheepdog)

>>  - the next 4 MB (8 MB ~ 12 MB) is allocated as the object 40003
>>  - the next 4 MB (12 MB ~ 16 MB) is allocated as the object 40004
>>  - ...
>>   (40000 is a vdi object, and contains metadata for the VM)
>>   
> I'll test 7) & 8) more thoroughly and get back to you with the results.

Thanks!

--
MORITA, Kazutaka