On Sat, Jun 09, 2012 at 01:18:52AM +0900, MORITA Kazutaka wrote:
Okay, let's leave it untouched for now. I think the real advantage
would be the optimization with splice system call mentioned by
Christoph. I'm looking forward to it.
Yes, I'll keep the patch in my queue until I get to start
On Wed, Jun 06, 2012 at 11:56:53AM +0800, Liu Yuan wrote:
The pros is simplification of code, but you don't say cons, I think we
should know the perf number we lost by adding a network overhead for IOs
happen to be local, this can be easily collected by built-in tracer.
What kind of setup do
On 06/06/2012 06:44 PM, Christoph Hellwig wrote:
On Wed, Jun 06, 2012 at 11:56:53AM +0800, Liu Yuan wrote:
The pros is simplification of code, but you don't say cons, I think we
should know the perf number we lost by adding a network overhead for IOs
happen to be local, this can be easily
On Wed, Jun 06, 2012 at 06:52:16PM +0800, Liu Yuan wrote:
At your convenience :) Maybe two (small cluster and bigger one) would
suffice. With cached FD pool, we might not lose that much performance
for a quick thought, though, but this is quite radical change of design,
numbers will definitely
On 06/06/2012 06:54 PM, Christoph Hellwig wrote:
On Wed, Jun 06, 2012 at 06:52:16PM +0800, Liu Yuan wrote:
At your convenience :) Maybe two (small cluster and bigger one) would
suffice. With cached FD pool, we might not lose that much performance
for a quick thought, though, but this is quite
Hi all,
firstly, its cool stuff you made :-)
Thanks to all participant.
Maybe it helps, if we can collect some use-cases here?
Am 2012-06-06 12:59, schrieb Liu Yuan:
On 06/06/2012 06:54 PM, Christoph Hellwig wrote:
I'd say performance numbers only start to really matter for 20,30+
nodes, or
On 06/06/2012 07:50 PM, Bastian Scholz wrote:
Hi all,
firstly, its cool stuff you made :-)
Thanks to all participant.
Maybe it helps, if we can collect some use-cases here?
Hi Bastian,
Thanks for your feedbacks. Yes, we are highly appreciated at
constructive feedback from end
On 06/07/2012 09:28 AM, MORITA Kazutaka wrote:
At Wed, 06 Jun 2012 18:52:16 +0800,
Liu Yuan wrote:
On 06/06/2012 06:44 PM, Christoph Hellwig wrote:
On Wed, Jun 06, 2012 at 11:56:53AM +0800, Liu Yuan wrote:
The pros is simplification of code, but you don't say cons, I think we
should know
Sheepdog is designed for clusters large enough that finding objects locally
is the exception, so stop optimizing for it. Remove all code that bypasses
the networking code when handling an object that is local to the gateway.
In the short runs the only benefits are code simplification, and not
On 06/05/2012 08:10 PM, Christoph Hellwig wrote:
Sheepdog is designed for clusters large enough that finding objects locally
is the exception, so stop optimizing for it. Remove all code that bypasses
the networking code when handling an object that is local to the gateway.
In the short
10 matches
Mail list logo
