[Sheepdog] Sheepdog 0.3.0 schedule and 0.4.0 plan

[Liu Yuan]

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?

Thanks,
Yuan