[Sheepdog] Sheepdog 0.3.0 schedule and 0.4.0 plan

Liu Yuan namei.unix at gmail.com
Tue Nov 15 12:26:55 CET 2011

On 11/15/2011 06:43 PM, Christoph Hellwig wrote:

> It's not going to help with read performance indeed.  In my benchmarks
> so read performance wasn't a major issue, mostly because I always had
> a copy of all objects stored on the machine where qemu runs.

So this is not true of most regular cases. Current consistent-hashing
will sprinkle objects all over the nodes of the cluster and the nodes
location are subjective to changing because of data rebalance at
membership change. No local copy kept.

> If you care about read performance having the objects locally is what
> you need - adding a config tweak that makes sure to keep a local copy
> of objects read at least once might be a good idea.

What do you mean exactly by 'config tweak'?

We might use readahead not only for performance, but also it improves
the availability on node basis. For e.g, if we read-ahead the whole
image locally, this node can work in a controlled state that it doesn't
care about other nodes at all, whether them be died or live in some sense.

> The proposal linked above probaby isn't too benefical for write
> performance, given that you only start pushing things to the network
> once the flush routine is called, and thus use a lot of bandwith in
> the latency critical flush roundtrip.  Sending unstable write requests
> to all nodes ASAP, and only doing the final sync on flush will get
> much better performance.

Yes, that will cause latency issue. But we are concerned about reducing
network traffic too, how is your plan going to reduce the network traffic?


More information about the sheepdog mailing list