All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boaz Harrosh <bharrosh@panasas.com>
To: "J. Bruce Fields" <bfields@fieldses.org>,
	"Welch, Brent" <welch@panasas.com>
Cc: sfaibish <sfaibish@emc.com>, NFS list <linux-nfs@vger.kernel.org>
Subject: Re: Performance results with exofs
Date: Tue, 08 Jun 2010 08:26:45 +0300	[thread overview]
Message-ID: <4C0DD495.5070908@panasas.com> (raw)
In-Reply-To: <20100607184902.GI25257@fieldses.org>

On 06/07/2010 09:49 PM, J. Bruce Fields wrote:
>>
>> It's a know problem with a network storage cluster. What happens is
>> that with 8of8 all the clients exercise all of the nodes at the same
>> time so they are clashing on the network.
> 
> OK, so if two clients are both trying to send a stripe of data to the
> same OSD data at the same time, absent a switch that could somehow
> afford to queue up a full stripe-unit's worth of data, packets get lost?
> 

It's tcp they don't get lost, per-se they just get queued up. And that tcp
ramp up and all that, you know. 

We use a 64k stripe unit with say raid of 4-8 that's 256k-1M bytes in a stripe.
I don't think a network buffer that big will help at all. It'll just delay
everything more. The best is a sound statistical network strategy that'll let
the system even out overall. (Or not ...)

> (Also, out of curiosity: do you know of any papers or documentation that
> describe that problem in more detail?)
> 

Personally, I'm privileged to learn from the best here at Panasas. 

CC: Brent, Can you recommend to Bruce some good papers about raid
groups and network SAN strategies? 

> --b.

Boaz

  reply	other threads:[~2010-06-08  5:26 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <op.vdxrrgf1unckof@usensfaibisl2e.eng.emc.com>
2010-06-07 16:07 ` Performance results with exofs Boaz Harrosh
2010-06-07 16:13   ` Boaz Harrosh
2010-06-07 17:28     ` sfaibish
     [not found]       ` <op.vdxxhfqsunckof-sXut7+96orlxdPWQvOaHCoI83tS8F2Zb0E9HWUfgJXw@public.gmane.org>
2010-06-07 17:29         ` Boaz Harrosh
2010-06-07 17:34           ` sfaibish
2010-06-07 18:29       ` J. Bruce Fields
2010-06-07 18:41         ` Boaz Harrosh
2010-06-07 18:49           ` J. Bruce Fields
2010-06-08  5:26             ` Boaz Harrosh [this message]
2010-06-08  6:54             ` Benny Halevy
2010-06-08 14:48               ` sfaibish
     [not found]                 ` <op.vdzkrtmqunckof-sXut7+96orlxdPWQvOaHCoI83tS8F2Zb0E9HWUfgJXw@public.gmane.org>
2010-06-08 23:15                   ` J. Bruce Fields
2010-06-07 18:43         ` Boaz Harrosh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C0DD495.5070908@panasas.com \
    --to=bharrosh@panasas.com \
    --cc=bfields@fieldses.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=sfaibish@emc.com \
    --cc=welch@panasas.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.