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