public inbox for linux-nfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "André Berger" <andre.berger-S0/GAf8tV78@public.gmane.org>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
	Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Subject: Re: NFS issues with recent kernels [long]
Date: Tue, 21 Apr 2009 06:36:43 +0200	[thread overview]
Message-ID: <20090421043642.GA52257@fuchs> (raw)
In-Reply-To: <F1250240-F050-47B7-9569-54941AAAD572@oracle.com>

* Chuck Lever (2009-04-20):
> On Apr 20, 2009, at 5:14 AM, Andr=E9 Berger wrote:
>> * Chuck Lever (2009-04-17):
>>> Copying linux-nfs@vger.kernel.org, please follow up there.
>>
>> OK, here we go. If anyone here doesn't want to receive these
>> messages, please let me know.
>>
>> It took me a while to get a tcpdump binary for the dbox2, hence the
>> delay and extensive quotes. The libc6 for tcpdump is itself located
>> on a NFS share.
>
>   [ ... ]
>
>>> You could try capturing a raw packet trace of the initial mount and=
 a=20
>>> few
>>> reads and write on the share.  The clients negotiate the rsize and =
=20
>>> wsize
>>> settings with the server, and the packet dump would expose the =20
>>> negotiated
>>> values.
>>>
>>> On your clients, use "tcpdump -s 0 -w /tmp/raw host" followed by th=
e=20
>>> DNS
>>> name of your server.  Then attach the raw pcap files to e-mail (as =
=20
>>> long as
>>> they are less than 100KB or so) and post them to linux-nfs-u79uwXL29TY@public.gmane.org=
nel.org
>>
>> Here you go. The host "192.168.1.8 hg linkstation" is specified in
>> /etc/hosts.
>>
>>>> For the sake of completeness, my router is a Linksys WRT54G
>>>>
>>>> with Tomato firmware
>>>>
>>>> <http://www.polarcloud.com/tomato_123>
>>>>
>>>> and a MTU of 1492 throughout the network.
>>>>
>>>> If there is anything I can do to help troubleshooting, please let =
me
>>>> know.
>
> I got two copies of this e-mail.  One has a 24KB PCAP file called "ra=
w"=20
> and the other has a 90KB file called "xap" that does not appear to be=
 a=20
> PCAP file.

The first message was too big for the list and bounced (172 KB). For
the second one (90KB raw size), I was unable to produce a dump small
enough, so I used split on it. I might have sent the wrong part
though.=20

> I looked at "raw" and it's hard to make sense of it.  I see both UDP =
and=20
> TCP traffic, and both NFSv2 and NFSv3 requests.  I guess this is beca=
use=20
> tcpdump is on NFS.  It would be better if you could copy the tcpdump=20
> binary to a local file system on the client before running the test t=
o=20
> avoid the extra traffic.

Space is very limited on the dbox, so I had to try and compile the
dbox2 Neutrino OS with tcpdump during the last couple of days.
Yesterday I succeeded, so I hope to boot the beast today.=20

> You should avoid UDP on this network at all costs, especially if you =
want=20
> to use large r/wsize.  It's likely that this is the real performance=20
> issue.  Specify "proto=3Dtcp" on your mount command line to force the=
 use of=20
> NFS/TCP.  Otherwise IP packet fragmentation and reassembly will cause=
=20
> dropped RPC requests, exacerbated by network link speed mismatches an=
d=20
> Ethernet frame collision on the half-duplex links.
>
> I believe the older 2.4-based NFS clients will use UDP by default.

Weird, I always got the best results with UDP for writing and TCP for
reading.=20

I'll try and produce a better, short tcpdump as soon as I can.

-Andr=E9

--=20
May as well be hung for a sheep as a lamb!
Linkstation/KuroBox/HG/HS/Tera Kernel 2.6/PPC from <http://hvkls.dyndns=
=2Eorg>
iPhone <http://hvkls.dyndns.org/downloads/documentation/README-iphone.h=
tml>

  reply	other threads:[~2009-04-21  4:36 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20090417102659.GC55096@fuchs>
2009-04-17 16:29 ` NFS issues with recent kernels [long] Chuck Lever
     [not found]   ` <20090420091454.GB614@fuchs>
2009-04-20 19:07     ` Chuck Lever
2009-04-21  4:36       ` André Berger [this message]
     [not found]         ` <20090508193813.GC3801@fuchs>
2009-05-08 20:00           ` Chuck Lever
2009-05-08 20:37             ` André Berger
2009-05-08 20:48               ` Trond Myklebust
     [not found]                 ` <1241815735.7291.1.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-05-09 18:57                   ` André Berger
2009-05-09 20:41                     ` Trond Myklebust
     [not found]                       ` <1241901691.5101.26.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-05-12  5:42                         ` André Berger

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=20090421043642.GA52257@fuchs \
    --to=andre.berger-s0/gaf8tv78@public.gmane.org \
    --cc=chuck.lever@oracle.com \
    --cc=g.liakhovetski@gmx.de \
    --cc=linux-nfs@vger.kernel.org \
    /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