mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: rettw@rtwnetwork.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: Strange NFS client behavior on 2.6.6 and higher {Scanned}
Date: Fri, 20 Aug 2004 16:40:20 -0400	[thread overview]
Message-ID: <1093034419.17122.49.camel@lade.trondhjem.org> (raw)
In-Reply-To: <32995.172.20.32.77.1093032267.squirrel@172.20.32.77>

På fr , 20/08/2004 klokka 16:04, skreiv Rett D. Walters:

> Using a 2.4 client, the file slowly counts up as data is
> written when pushing to a 2.4 server.  Using 2.6.6 against
> a 2.6 server the file is written in large multi-megabyte
> clumps instead.

Probably. The VM decides when to push out data in 2.6.x. In 2.4.x we had
artificial hard limits on the number of dirty pages that were allowed to
exist, now all that is controlled by the VM.

>   However using a 2.6.6 client against a
> 2.4 server acts just like it used to, with a "trickle"
> write.

Huh?

>   A tcpdump trace of the 2.6.6 client against a 2.6
> server show no traffic being transmitted and then suddenly
> a burst of 20,000 packets sent then nothing, until the
> next burst.

See above. Note that this is pretty much the way block devices work
too...

> It appears to me that the 2.6.6 client against a 2.6
> server scenario that the 2.6.6 client is caching the data
> then writing it in these large clumps.  As a data comm
> engineer by profession, this seems a little strange. 
> Sending 20000 packets in large, very fast bursts will
> increase the likelyhood of causing congestion at the
> receiver which could lead to packet loss.

That's why we have added TCP support as well as congestion control
algorithms for UDP. I've seen no signs of new congestion issues with
2.6.x in tests on a clean network. Rather I've seen vastly improved
write performance against faster servers precisely because the new
VM-driven stuff allows us to cache more data both on the client and the
server side.

> I am using NFS v3 over UDP, and have tried using async and sync, and
> setting the rsize/wsize to 8k etc to no avail.

It sounds to me as if you really want to be using O_SYNC or (better
still) O_DIRECT writes. You basically want to stream the data to the
server immediately without any caching right?

The "sync" mount option should also give you similar behaviour.

Cheers,
  Trond

      reply	other threads:[~2004-08-20 20:44 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-20 20:04 Rett D. Walters
2004-08-20 20:40 ` Trond Myklebust [this message]

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=1093034419.17122.49.camel@lade.trondhjem.org \
    --to=trond.myklebust@fys.uio.no \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rettw@rtwnetwork.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®