[sheepdog] Sheepdog design
Hitoshi Mitake
mitake.hitoshi at gmail.com
Mon Apr 25 07:31:30 CEST 2016
Hi Wei, sorry for my late reply.
Sheepdog uses a mechanism of virtual synchrony [1] for membership change.
Under this mechanism, join/leave of a member increases an epoch number.
When a sheep process receives a request from a client (including qemu and
tgt), it assigns its epoch number to the request and forwards the request
based on consistent hashing. Based on the epoch number in the request,
sheep can know the staleness of the request. The logic is not so simple but
you can follow the literal SD_RES_OLD_NODE_VER in the source code and get
hints about how it works.
Please send more questions if you want to know more details.
Thanks,
Hitoshi
[1] https://www.cs.cornell.edu/ken/history.pdf
On Tue, Apr 12, 2016 at 5:06 AM, Xie, Wei <wei.xie at ttu.edu> wrote:
> Hi,
> I’m doing a research based on Sheepdog that I have a question that how
> Sheepdog handles the addition of Sheep servers. I know that data should be
> automatically balanced when a new server is added. But I wonder how
> Sheepdog ensures the consistency of data and to synchronize the node
> membership changes to all the servers that each server will have the same
> data placement decision. For example, new data could be written before the
> new node membership information is synchronized to all the nodes and those
> at a stale state might forward data to an incorrect location. I would
> appreciate it if someone familiar with the source code can give me some
> idea.
>
> Thanks!
>
> Wei Xie
> Texas Tech University
> --
> sheepdog mailing list
> sheepdog at lists.wpkg.org
> https://lists.wpkg.org/mailman/listinfo/sheepdog
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wpkg.org/pipermail/sheepdog/attachments/20160425/794cf04d/attachment.html>
More information about the sheepdog
mailing list