Re: Is tcp autotuning really what NFS wants?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 07/14/2013 09:35 PM, NeilBrown wrote:
On Wed, 10 Jul 2013 10:39:38 -0700 Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote:

On 07/10/2013 10:33 AM, Dean wrote:
  > This could significantly limit the amount of parallelism that can be achieved for a single TCP connection (and given that the
  > Linux client strongly prefers a single connection now, this could become more of an issue).

I understand the simplicity in using a single tcp connection, but performance-wise it is definitely not the way to go on WAN links. When even a miniscule amount
of packet loss is added to the link (<0.001% packet loss), the tcp buffer collapses and performance drops significantly (especially on 10GigE WAN links).  I
think new TCP algorithms could help the problem somewhat, but nothing available today makes much of a difference vs. cubic.

Using multiple tcp connections allows better saturation of the link, since when packet loss occurs on a stream, the other streams can fill the void.  Today, the
only solution is to scale up the number of physical clients, which has high coordination overhead, or use a wan accelerator such as Bitspeed or Riverbed (which
comes with its own issues such as extra hardware, cost, etc).

I have a set of patches that allows one to do multiple unique mounts to the same server from a single
client, but the patches are for the client side, so it would not help
non-Linux clients.  And, the patches were rejected for upstream as not being
useful.  But, if you are interested in such, please let me know and I can point
you to them...

Yes please!


I haven't ported these forward to 3.10 yet, but you can find my 3.9 tree
here:

http://dmz2.candelatech.com/git/gitweb.cgi?p=linux-3.9.dev.y/.git;a=summary

There's a bunch of other patches, but the nfs related ones are all in a row
and the patches are rebased, so you can probably pull them out w/out
too much difficulty.  The patches introduce a bug where it fails to compile
w/out NFS 4.1 defined..I haven't bothered to fix it yet but it's probably
simple..or just compile with NFS 4.1 as I do.

Older trees found here, but we don't bother back-porting many patches,
so I'd use the latest if you can.

http://dmz2.candelatech.com/git/gitweb.cgi

And, you'll need a patched mount.nfs:

https://github.com/greearb/nfs-utils-ct

I hope to get started on porting these to 3.10 later this week..  If
there is any interest in this patch series or something like it going
upstream (there wasn't in the past, I've no good reason to think that
has changed), let me know and I will clean them up and post them to
the mailing list again...

If you search for greearb@xxxxxxxxxxxxxxx and 'bind to local' you
can find previous threads in the mailing list archives...

Thanks,
Ben


--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc  http://www.candelatech.com

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux