[Sheepdog] Sheepdog 0.3.0 schedule and 0.4.0 plan

[Christoph Hellwig]

On Tue, Nov 15, 2011 at 07:26:55PM +0800, Liu Yuan wrote:
> 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.

Yes - I just meant to say that so far I didn't trigger read performance
issue yet - they onbviously exist if data is far away.

> > 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'?

In a setup where all nodes are close to each other and the qemu instance
migrating data to be local on a read isn't going to help much, so
behaviour to do this should not be unconditionally.

> 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.

Yes.  I'm very interested in a model like that.

> > 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?

Maybe I haven't understood the linked model yet, but I don't see how it
reduces network traffic either.