Re: NFS issues with recent kernels [long]

Re: NFS issues with recent kernels [long]

[Chuck Lever]

Copying linux-nfs@vger.kernel.org, please follow up there.

On Apr 17, 2009, at 6:27 AM, Andr=E9 Berger wrote:

> I'm experiencing NFS [rw]size problems ever since kernel 2.6.18.8,
> which allowed for [rw]size=3D32768. Every kernel 2.16.19-29.6.25.20 (=
I
> tried every single subrevision) gave me only 8K mount results. Before
> I come to 2.6.29.1 and my current configuration, let me give you a
> short overview.

To summarize, you are running late model 2.6 kernels on a NAS =20
appliance, and your 2.4 clients are having trouble using large rsize =20
and wsize.

> My system was a Buffalo Linkstation ("LS1"), a PPC model,
>
>  <http://buffalo.nas-central.org/wiki/Category:LS1>
>
> with Debian etch and its NFS kernel server. The kernels < 2.6.20 were
> essentially compiled on a kernel.org or Debian etch basis, plus the
> patches from
>
>  <http://www.genbako.com/>
>
> while 2.6.20-2.6.25.20 were compiled from Sylver's
>
>  <http://linkstationwiki.svn.sourceforge.net/viewvc/linkstationwiki/k=
ernel_universal/=20
> >
>
> modified sources. Please find all .configs attached.
>
>
> The clients are Nokia and Sagem dboxII with kernel
>
>  Linux nokia 2.4.32-dbox2 #1 Do Aug 31 20:09:34 CEST 2006 ppc unknown
>
> with 10MBit Half Duplex Ethernet interfaces and Neutrino software, se=
e
>
>  <http://wiki.tuxbox.org/>
>
> for details.
>
>
> /etc/exports has never changed,
>
>  /mnt/media/incoming/movies =20
> 192.168.1.0=20
> /24(rw,async,no_subtree_check,all_squash,anonuid=3D1000,anongid=3D100=
0)
>
> The results vary, depending on the kernel. With 2.6.18, I used to get
>
>  192.168.1.8:/mnt/media/incoming/movies on /var/autofs/record type =20
> nfs (rw,v3,rsize=3D32768,wsize=3D32768,soft,udp,nolock,addr=3D192.168=
=2E1.8)
>
>  etc., for both TCP and UDP, on both dbox models.
>
> While I got only 8K with my LS1, my HG
>
>  <http://buffalo.nas-central.org/wiki/Category:HG>
>
> with 2.6.25.20 and 2.6.29.1 gives me 16K, but still not 32K. The
> numbers are related to the performance, 8K mounts make it impossible
> for me to use the LS as a VCR. 16K mounts seem to be better, but
> haven't been stress-tested yet here, as Cable TV bitrates vary.

Even with NFS/TCP ?  Oh, I see -- the clients are 10Mbit half-duplex.

> After an upgrade from Buffalo's bootloader in FLash ROM to uboot, I
> have been unable to boot non-flat device tree kernels like 2.6.18,
> and switched from the LS1 to the HG model in the troubleshooting
> process. As the latests kernels still don't reach 32K on that system
> either, I suspect a bug.

Any relevant messages in the kernel log on either the client or server?

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 the =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@vger=
=2Ekernel.org=20
=2E

> 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.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: NFS issues with recent kernels [long]

[Chuck Lever]

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 =
=20
>> a 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 =20
>> the 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-u79uwXL29Tb/PtFMR13I2A@public.gmane.org=
el.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 m=
e
>>> know.

I got two copies of this e-mail.  One has a 24KB PCAP file called =20
"raw" and the other has a 90KB file called "xap" that does not appear =20
to be a PCAP file.

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

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

I believe the older 2.4-based NFS clients will use UDP by default.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: NFS issues with recent kernels [long]

[André Berger]

* 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>

Re: NFS issues with recent kernels [long]

[Chuck Lever]

On May 8, 2009, at 3:38 PM, Andr=E9 Berger wrote:
> * Andr=E9 Berger (2009-04-21):
>> * 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 th=
e
>>>> delay and extensive quotes. The libc6 for tcpdump is itself locate=
d
>>>> on a NFS share.
>>>
>>>  [ ... ]
>>>
>>>>> You could try capturing a raw packet trace of the initial mount =20
>>>>> and a
>>>>> few
>>>>> reads and write on the share.  The clients negotiate the rsize an=
d
>>>>> 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 =
=20
>>>>> the
>>>>> DNS
>>>>> name of your server.  Then attach the raw pcap files to e-mail (a=
s
>>>>> long as
>>>>> they are less than 100KB or so) and post them to linux-nfs@vger.k=
ernel.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 =20
>>>>>> let me
>>>>>> know.
>>>
>>> I got two copies of this e-mail.  One has a 24KB PCAP file called =20
>>> "raw"
>>> and the other has a 90KB file called "xap" that does not appear to =
=20
>>> 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 =20
>>> UDP and
>>> TCP traffic, and both NFSv2 and NFSv3 requests.  I guess this is =20
>>> because
>>> tcpdump is on NFS.  It would be better if you could copy the tcpdum=
p
>>> binary to a local file system on the client before running the =20
>>> 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 =20
>>> you want
>>> to use large r/wsize.  It's likely that this is the real performanc=
e
>>> issue.  Specify "proto=3Dtcp" on your mount command line to force =20
>>> the use of
>>> NFS/TCP.  Otherwise IP packet fragmentation and reassembly will =20
>>> cause
>>> dropped RPC requests, exacerbated by network link speed mismatches =
=20
>>> 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 fo=
r
>> reading.
>>
>> I'll try and produce a better, short tcpdump as soon as I can.
>
> After some difficulties, here we go!
>
> -Andr=E9
>
> --
> May as well be hung for a sheep as a lamb!
> Linkstation/KuroBox/HG/HS/Tera Kernel 2.6/PPC from <http://hvkls.dynd=
ns.org=20
> >
> iPhone <http://hvkls.dyndns.org/downloads/documentation/README-iphone=
=2Ehtml=20
> >
> <raw>

Assuming 192.168.1.8 is your server, frame 79 and 622 report FSINFO =20
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... . =3D SETATTR can set time on server
         .1.. . =3D PATHCONF is valid for all files
         ...1 . =3D File System supports symbolic links
         .... 1 =3D File System supports hard links

says your server operating system supports NFS rsize and wsize maxima =20
of 16384 bytes.

RFC 1813:
> rtmax
> The maximum size in bytes of a READ request supported by the server. =
=20
> Any READ with a number greater than rtmax will result in a short =20
> read of rtmax bytes or less.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: NFS issues with recent kernels [long]

[André Berger]

* Chuck Lever (2009-05-08):
> On May 8, 2009, at 3:38 PM, Andr=E9 Berger wrote:
>> * Andr=E9 Berger (2009-04-21):
>>> * Chuck Lever (2009-04-20):
>>>> On Apr 20, 2009, at 5:14 AM, Andr=E9 Berger wrote:
>>>>> * Chuck Lever (2009-04-17):
[...]
> Assuming 192.168.1.8 is your server, frame 79 and 622 report FSINFO =20
> 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... . =3D SETATTR can set time on server
>         .1.. . =3D PATHCONF is valid for all files
>         ...1 . =3D File System supports symbolic links
>         .... 1 =3D File System supports hard links
>
> says your server operating system supports NFS rsize and wsize maxima=
 of=20
> 16384 bytes.
>
> RFC 1813:
>> rtmax
>> The maximum size in bytes of a READ request supported by the server.=
 =20
>> Any READ with a number greater than rtmax will result in a short rea=
d of=20
>> rtmax bytes or less.

My OS is 2.6.29.2, Debian etch, on a PPC system. I swear I got 32K
[rw]size with kernels < 2.6.19, at least "mount" reported them as
such. With recent kernels, "mount" and your analysis agree on just
16K. So, what can I do?

-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>

Re: NFS issues with recent kernels [long]

[Trond Myklebust]

On Fri, 2009-05-08 at 22:37 +0200, Andr=C3=A9 Berger wrote:
> * Chuck Lever (2009-05-08):
> > On May 8, 2009, at 3:38 PM, Andr=C3=A9 Berger wrote:
> >> * Andr=C3=A9 Berger (2009-04-21):
> >>> * Chuck Lever (2009-04-20):
> >>>> On Apr 20, 2009, at 5:14 AM, Andr=C3=A9 Berger wrote:
> >>>>> * Chuck Lever (2009-04-17):
> [...]
> > Assuming 192.168.1.8 is your server, frame 79 and 622 report FSINFO=
 =20
> > 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... . =3D SETATTR can set time on server
> >         .1.. . =3D PATHCONF is valid for all files
> >         ...1 . =3D File System supports symbolic links
> >         .... 1 =3D File System supports hard links
> >
> > says your server operating system supports NFS rsize and wsize maxi=
ma of=20
> > 16384 bytes.
> >
> > RFC 1813:
> >> rtmax
> >> The maximum size in bytes of a READ request supported by the serve=
r. =20
> >> Any READ with a number greater than rtmax will result in a short r=
ead of=20
> >> rtmax bytes or less.
>=20
> My OS is 2.6.29.2, Debian etch, on a PPC system. I swear I got 32K
> [rw]size with kernels < 2.6.19, at least "mount" reported them as
> such. With recent kernels, "mount" and your analysis agree on just
> 16K. So, what can I do?

There is nothing the client can do as long as the server says it won't
accept NFS requests with read or write sizes > 16k. You therefore need
to fix the server.

Trond

Re: NFS issues with recent kernels [long]

[André Berger]

* Trond Myklebust (2009-05-08):
> On Fri, 2009-05-08 at 22:37 +0200, Andr=C3=A9 Berger wrote:
> > * Chuck Lever (2009-05-08):
> > > On May 8, 2009, at 3:38 PM, Andr=C3=A9 Berger wrote:
> > >> * Andr=C3=A9 Berger (2009-04-21):
> > >>> * Chuck Lever (2009-04-20):
> > >>>> On Apr 20, 2009, at 5:14 AM, Andr=C3=A9 Berger wrote:
> > >>>>> * Chuck Lever (2009-04-17):
> > [...]
> > > Assuming 192.168.1.8 is your server, frame 79 and 622 report FSIN=
=46O =20
> > > 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... . =3D SETATTR can set time on server
> > >         .1.. . =3D PATHCONF is valid for all files
> > >         ...1 . =3D File System supports symbolic links
> > >         .... 1 =3D File System supports hard links
> > >
> > > says your server operating system supports NFS rsize and wsize ma=
xima of=20
> > > 16384 bytes.
> > >
> > > RFC 1813:
> > >> rtmax
> > >> The maximum size in bytes of a READ request supported by the ser=
ver. =20
> > >> Any READ with a number greater than rtmax will result in a short=
 read of=20
> > >> rtmax bytes or less.
> >=20
> > My OS is 2.6.29.2, Debian etch, on a PPC system. I swear I got 32K
> > [rw]size with kernels < 2.6.19, at least "mount" reported them as
> > such. With recent kernels, "mount" and your analysis agree on just
> > 16K. So, what can I do?
>=20
> There is nothing the client can do as long as the server says it won'=
t
> accept NFS requests with read or write sizes > 16k. You therefore nee=
d
> to fix the server.

So what can I do to fix this? I've upgraded to nfs-utils-1.1.4 in the
meantime, 1.1.5 and both 1.1.6 give me=20

  make[2]: Entering directory `/tmp/nfs-utils-1.1.5/support/misc'
  gcc -DHAVE_CONFIG_H -I. -I../../support/include   -I/usr/include  -D_=
GNU_SOURCE -Wall -Wstrict-prototypes  -pipe -g -O2 -MT tcpwrapper.o -MD=
 -MP -MF .deps/tcpwrapper.Tpo -c -o tcpwrapper.o tcpwrapper.c
  tcpwrapper.c: In function =E2=80=98haccess_add=E2=80=99:
  tcpwrapper.c:117: warning: implicit declaration of function =E2=80=98=
TAILQ_EMPTY=E2=80=99
  tcpwrapper.c:119: error: expected expression before =E2=80=98else=E2=80=
=99
  tcpwrapper.c: In function =E2=80=98haccess_lookup=E2=80=99:
  tcpwrapper.c:131: warning: implicit declaration of function =E2=80=98=
TAILQ_FOREACH=E2=80=99
  tcpwrapper.c:131: error: =E2=80=98list=E2=80=99 undeclared (first use=
 in this function)
  tcpwrapper.c:131: error: (Each undeclared identifier is reported only=
 once
  tcpwrapper.c:131: error: for each function it appears in.)
  tcpwrapper.c:131: error: expected =E2=80=98;=E2=80=99 before =E2=80=98=
{=E2=80=99 token
  make[2]: *** [tcpwrapper.o] Error 1
  make[2]: Leaving directory `/tmp/nfs-utils-1.1.5/support/misc'
  make[1]: *** [all-recursive] Error 1
  make[1]: Leaving directory `/tmp/nfs-utils-1.1.5/support'
  make: *** [all-recursive] Error 1

with=20

  ./configure --prefix=3D/usr/local --sysconfdir=3D/etc --with-tcp-wrap=
pers=3D/usr/include --with-statedir=3D/var/lib/nfs

I've already upgraded tcpd to the Lenny version 7.6.q-16 (from
source), but that didn't help.=20

With 1.1.4, I still get 16384 [rw]size while 32768 were requested.=20

-Andr=C3=A9

--=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>

Re: NFS issues with recent kernels [long]

[Trond Myklebust]

On Sat, 2009-05-09 at 20:57 +0200, André Berger wrote:
> * Trond Myklebust (2009-05-08):
> > On Fri, 2009-05-08 at 22:37 +0200, André Berger wrote:
> > > * Chuck Lever (2009-05-08):
> > > > 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):
> > > [...]
> > > > 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.
> > > 
> > > My OS is 2.6.29.2, Debian etch, on a PPC system. I swear I got 32K
> > > [rw]size with kernels < 2.6.19, at least "mount" reported them as
> > > such. With recent kernels, "mount" and your analysis agree on just
> > > 16K. So, what can I do?
> > 
> > There is nothing the client can do as long as the server says it won't
> > accept NFS requests with read or write sizes > 16k. You therefore need
> > to fix the server.
> 
> So what can I do to fix this? I've upgraded to nfs-utils-1.1.4 in the
> meantime, 1.1.5 and both 1.1.6 give me 
> 
>   make[2]: Entering directory `/tmp/nfs-utils-1.1.5/support/misc'
>   gcc -DHAVE_CONFIG_H -I. -I../../support/include   -I/usr/include  -D_GNU_SOURCE -Wall -Wstrict-prototypes  -pipe -g -O2 -MT tcpwrapper.o -MD -MP -MF .deps/tcpwrapper.Tpo -c -o tcpwrapper.o tcpwrapper.c
>   tcpwrapper.c: In function ‘haccess_add’:
>   tcpwrapper.c:117: warning: implicit declaration of function ‘TAILQ_EMPTY’
>   tcpwrapper.c:119: error: expected expression before ‘else’
>   tcpwrapper.c: In function ‘haccess_lookup’:
>   tcpwrapper.c:131: warning: implicit declaration of function ‘TAILQ_FOREACH’
>   tcpwrapper.c:131: error: ‘list’ undeclared (first use in this function)
>   tcpwrapper.c:131: error: (Each undeclared identifier is reported only once
>   tcpwrapper.c:131: error: for each function it appears in.)
>   tcpwrapper.c:131: error: expected ‘;’ before ‘{’ token
>   make[2]: *** [tcpwrapper.o] Error 1
>   make[2]: Leaving directory `/tmp/nfs-utils-1.1.5/support/misc'
>   make[1]: *** [all-recursive] Error 1
>   make[1]: Leaving directory `/tmp/nfs-utils-1.1.5/support'
>   make: *** [all-recursive] Error 1
> 
> with 
> 
>   ./configure --prefix=/usr/local --sysconfdir=/etc --with-tcp-wrappers=/usr/include --with-statedir=/var/lib/nfs
> 
> I've already upgraded tcpd to the Lenny version 7.6.q-16 (from
> source), but that didn't help. 
> 
> With 1.1.4, I still get 16384 [rw]size while 32768 were requested. 


If the server is based on a recent Linux kernel, then you should check
the value of /proc/fs/nfsd/max_block_size. If it is less than 32k, then
try increasing it.

Cheers
  Trond

Re: NFS issues with recent kernels [long]

[André Berger]

* Trond Myklebust (2009-05-09):
> On Sat, 2009-05-09 at 20:57 +0200, Andr=C3=A9 Berger wrote:
> > * Trond Myklebust (2009-05-08):
> > > On Fri, 2009-05-08 at 22:37 +0200, Andr=C3=A9 Berger wrote:
> > > > * Chuck Lever (2009-05-08):
> > > > > On May 8, 2009, at 3:38 PM, Andr=C3=A9 Berger wrote:
> > > > >> * Andr=C3=A9 Berger (2009-04-21):
> > > > >>> * Chuck Lever (2009-04-20):
> > > > >>>> On Apr 20, 2009, at 5:14 AM, Andr=C3=A9 Berger wrote:
> > > > >>>>> * Chuck Lever (2009-04-17):
> > > > [...]
> > > > > Assuming 192.168.1.8 is your server, frame 79 and 622 report =
=46SINFO =20
> > > > > 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... . =3D SETATTR can set time on server
> > > > >         .1.. . =3D PATHCONF is valid for all files
> > > > >         ...1 . =3D File System supports symbolic links
> > > > >         .... 1 =3D File System supports hard links
> > > > >
> > > > > says your server operating system supports NFS rsize and wsiz=
e maxima of=20
> > > > > 16384 bytes.
> > > > >
> > > > > RFC 1813:
> > > > >> rtmax
> > > > >> The maximum size in bytes of a READ request supported by the=
 server. =20
> > > > >> Any READ with a number greater than rtmax will result in a s=
hort read of=20
> > > > >> rtmax bytes or less.
> > > >=20
> > > > My OS is 2.6.29.2, Debian etch, on a PPC system. I swear I got =
32K
> > > > [rw]size with kernels < 2.6.19, at least "mount" reported them =
as
> > > > such. With recent kernels, "mount" and your analysis agree on j=
ust
> > > > 16K. So, what can I do?
> > >=20
> > > There is nothing the client can do as long as the server says it =
won't
> > > accept NFS requests with read or write sizes > 16k. You therefore=
 need
> > > to fix the server.
> >=20
> > So what can I do to fix this? I've upgraded to nfs-utils-1.1.4 in t=
he
> > meantime, 1.1.5 and both 1.1.6 give me=20
> >=20
> >   make[2]: Entering directory `/tmp/nfs-utils-1.1.5/support/misc'
> >   gcc -DHAVE_CONFIG_H -I. -I../../support/include   -I/usr/include =
 -D_GNU_SOURCE -Wall -Wstrict-prototypes  -pipe -g -O2 -MT tcpwrapper.o=
 -MD -MP -MF .deps/tcpwrapper.Tpo -c -o tcpwrapper.o tcpwrapper.c
> >   tcpwrapper.c: In function =E2=80=98haccess_add=E2=80=99:
> >   tcpwrapper.c:117: warning: implicit declaration of function =E2=80=
=98TAILQ_EMPTY=E2=80=99
> >   tcpwrapper.c:119: error: expected expression before =E2=80=98else=
=E2=80=99
> >   tcpwrapper.c: In function =E2=80=98haccess_lookup=E2=80=99:
> >   tcpwrapper.c:131: warning: implicit declaration of function =E2=80=
=98TAILQ_FOREACH=E2=80=99
> >   tcpwrapper.c:131: error: =E2=80=98list=E2=80=99 undeclared (first=
 use in this function)
> >   tcpwrapper.c:131: error: (Each undeclared identifier is reported =
only once
> >   tcpwrapper.c:131: error: for each function it appears in.)
> >   tcpwrapper.c:131: error: expected =E2=80=98;=E2=80=99 before =E2=80=
=98{=E2=80=99 token
> >   make[2]: *** [tcpwrapper.o] Error 1
> >   make[2]: Leaving directory `/tmp/nfs-utils-1.1.5/support/misc'
> >   make[1]: *** [all-recursive] Error 1
> >   make[1]: Leaving directory `/tmp/nfs-utils-1.1.5/support'
> >   make: *** [all-recursive] Error 1
> >=20
> > with=20
> >=20
> >   ./configure --prefix=3D/usr/local --sysconfdir=3D/etc --with-tcp-=
wrappers=3D/usr/include --with-statedir=3D/var/lib/nfs
> >=20
> > I've already upgraded tcpd to the Lenny version 7.6.q-16 (from
> > source), but that didn't help.=20
> >=20
> > With 1.1.4, I still get 16384 [rw]size while 32768 were requested.=20
>=20
>=20
> If the server is based on a recent Linux kernel, then you should chec=
k
> the value of /proc/fs/nfsd/max_block_size. If it is less than 32k, th=
en
> try increasing it.

Indeed, that does the trick with 2.6.29.3 :)

Thank you very much, everyone!

-Andr=C3=A9

--=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>