[sheepdog] [PATCH 0/9] revive VDI locking mecahnism

[Fabian Zimmermann]

Hi,
> Under the vdi locking scheme implemented in this patchset, VDI release
> will be caused in the below 3 cases:
>
> 1. qemu explicitly releases its VDI
> 2. qemu process dies
> 3. sheep process dies (in this case, VDIs opened by qemu processes
> which connect to the sheep process as a gateway will be released)
>
> On the second thought, the case 2 and 3 are not so good for
> integrity of VDI data. Because in such cases, write requests for
> objects of the VDIs can be stopped before completion. It can introduce
> inconsistent state of the objects. For example, assume that before the
> stopped write request, contents of the objects are A, A, A (3
> replica). The sheep can die after the second write request is
> issued. After that, replicas can be B, B, A. If new qemu process tries
> to read the object, sheep can return both of B and A because sheep
> issues read request to one randomly choosed node from 3 nodes. This
> behavior breaks the semantics of block device!
>
> So I think it is safe to require "force unlocking + dog vdi check"
> before launching new qemu for the cases of sudden death of qemu and
> node leaving. How do you think?
first, thanks a lot for the work. I'm really glad to have this feature
in the near future.

I think it "force unlocking + dog vdi check" is fine, but may I add
another question:

When is a write-cmd returned? As soon as a quorum is acked by
sheepdog-processes?

I'm asking because if replicas are B, A, A and clients thinks "B" is
written. vdi-check would (correct me if I'm wrong) assume A as correct
and overwrite the B-data, so ideally client shouldn't have got his
write-cmd back, else this would lead to an inconsistent state, isn't it?

Thanks,

Fabian