On May 8, 2009, at 3:38 PM, André Berger wrote:
* André Berger (2009-04-21):
* Chuck Lever (2009-04-20):
On Apr 20, 2009, at 5:14 AM, André Berger wrote:
* Chuck Lever (2009-04-17):
Copying linux-nfs@xxxxxxxxxxxxxxx, 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
few
reads and write on the share. The clients negotiate the rsize and
wsize
settings with the server, and the packet dump would expose the
negotiated
values.
On your clients, use "tcpdump -s 0 -w /tmp/raw host" followed by
the
DNS
name of your server. Then attach the raw pcap files to e-mail (as
long as
they are less than 100KB or so) and post them to linux-nfs@xxxxxxxxxxxxxxx
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
"raw"
and the other has a 90KB file called "xap" that does not appear to
be a
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.
I looked at "raw" and it's hard to make sense of it. I see both
UDP and
TCP traffic, and both NFSv2 and NFSv3 requests. I guess this is
because
tcpdump is on NFS. It would be better if you could copy the tcpdump
binary to a local file system on the client before running the
test to
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.
You should avoid UDP on this network at all costs, especially if
you want
to use large r/wsize. It's likely that this is the real performance
issue. Specify "proto=tcp" on your mount command line to force
the use of
NFS/TCP. Otherwise IP packet fragmentation and reassembly will
cause
dropped RPC requests, exacerbated by network link speed mismatches
and
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.
I'll try and produce a better, short tcpdump as soon as I can.
After some difficulties, here we go!
-André
--
May as well be hung for a sheep as a lamb!
Linkstation/KuroBox/HG/HS/Tera Kernel 2.6/PPC from <http://hvkls.dyndns.org
>
iPhone <http://hvkls.dyndns.org/downloads/documentation/README-iphone.html
>
<raw>
Assuming 192.168.1.8 is your server, frame 79 and 622 report FSINFO
results:
Network File System, FSINFO Reply
[Program Version: 3]
[V3 Procedure: FSINFO (19)]
Status: NFS3_OK (0)
obj_attributes
attributes_follow: no value (0)
rtmax: 16384
rtpref: 16384
rtmult: 4096
wtmax: 16384
wtpref: 16384
wtmult: 4096
dtpref: 4096
maxfilesize: 2194719883264
time delta: 1.000000000 seconds
seconds: 1
nano seconds: 0
Properties: 0x0000001b
1... . = SETATTR can set time on server
.1.. . = PATHCONF is valid for all files
...1 . = File System supports symbolic links
.... 1 = File System supports hard links
says your server operating system supports NFS rsize and wsize maxima
of 16384 bytes.
RFC 1813:
rtmax
The maximum size in bytes of a READ request supported by the server.
Any READ with a number greater than rtmax will result in a short
read of rtmax bytes or less.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]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
