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 -- sheepdog mailing list sheepdog@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/sheepdog
