RE: nfs: server X not responding, still trying

RE: nfs: server X not responding, still trying

[Lever, Charles]

it was pointed out to me that this was not entirely clear:

> > The client mount/fstab options are:
> > "rw,async,intr,vers=3D3,rsize=3D32768,wsize=3D32768" and the=20
> > server's exports
> > options are: "rw,no_root_squash,async,no_subtree_check".
>=20
> i am obligated to provide a friendly warning about using
> the "async" export option.  see the Linux NFS FAQ
> (http://nfs.sourceforge.net) for details.
>=20
> the async mount option is not needed, as async is the default.

the async export option is to be avoided.
          ^^^^^^
the async mount option is superfluous.
          ^^^^^

especially with NFSv3, async in either place is really not
necessary.  the Linux NFS FAQ has some explanatory text that
details why this is the case.


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: nfs: server X not responding, still trying

[Timothy G. Wesemann]

>> the async mount option is not needed, as async is the default.
>the async export option is to be avoided.

If that is so, then why does my exportfs (from nfs-utils-1.0.6) state the
following when exporting?

=================================
   exportfs: /etc/exports [4]: No 'sync' or 'async' option specified for
export "192.168.10.0/24:/jetstor/incoming".
      Assuming default behaviour ('sync').
      NOTE: this default has changed from previous versions
=================================

--
Tim Wesemann



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

RE: nfs: server X not responding, still trying

[Lever, Charles]

> >> the async mount option is not needed, as async is the default.
> >the async export option is to be avoided.
>=20
> If that is so, then why does my exportfs (from=20
> nfs-utils-1.0.6) state the
> following when exporting?
>=20
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
>    exportfs: /etc/exports [4]: No 'sync' or 'async' option=20
> specified for
> export "192.168.10.0/24:/jetstor/incoming".
>       Assuming default behaviour ('sync').
>       NOTE: this default has changed from previous versions
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D

because the previous default behavior was "async" and that
has changed recently.


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

RE: nfs: server X not responding, still trying

[Lever, Charles]

> The client mount/fstab options are:
> "rw,async,intr,vers=3D3,rsize=3D32768,wsize=3D32768" and the=20
> server's exports
> options are: "rw,no_root_squash,async,no_subtree_check".

i am obligated to provide a friendly warning about using
the "async" export option.  see the Linux NFS FAQ
(http://nfs.sourceforge.net) for details.

the async mount option is not needed, as async is the default.

with UDP, we usually recommend using a smaller rsize and wsize,
say, 8192, because large requests are more likely to overrun
switch port buffers and socket buffers.

> After digging through the archives, I found some references to Trond's
> patches for 2.4.22 (which didn't seem to help in this=20
> situation) as well as
> suggestions to revert back to 2.4.20 which seem to have helped the
> situation. I also tried using TCP which worked great, but the=20
> performance hit was too great.

what was the performance difference between UDP and TCP?

> These error accumulations now are much more rare with 2.4.20,=20
> however they
> still exist and performance is still not what it should be.=20
> Also, we really
> would prefer to run current release-quality kernel revs.

what you describe sounds like a networking problem.  since
your client and server are both linux systems, you can do
some end-to-end network performance testing.  i recommend
iperf (google) with both UDP and TCP.  you may find that
your switch is dropping packets even though your network
is not congested.


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

nfs: server X not responding, still trying

[Timothy G. Wesemann]

Hola,

I have a number of client boxes that are mounting a single nfs file-server
(presently all machines are slackware 9.0; nfs-utils-1.0.6; 2.4.20 kernel)
over a 100bt switched private network which is not congested at all. The
machines are all using the original Becker EtherExpressPro/100 kernel
modules statically compiled.

When all of the above machines were running 2.4.22, each machine had a
*constant* barrage of these in the syslog:

Nov  3 15:44:24 hostXX kernel: nfs: server fileserver-priv not responding,
still trying
Nov  3 15:44:25 hostXX kernel: nfs: server fileserver-priv OK
Nov  3 15:46:17 hostXX kernel: nfs: server fileserver-priv not responding,
still trying
Nov  3 15:46:17 hostXX kernel: nfs: server fileserver-priv OK

The client mount/fstab options are:
"rw,async,intr,vers=3,rsize=32768,wsize=32768" and the server's exports
options are: "rw,no_root_squash,async,no_subtree_check".

After digging through the archives, I found some references to Trond's
patches for 2.4.22 (which didn't seem to help in this situation) as well as
suggestions to revert back to 2.4.20 which seem to have helped the
situation. I also tried using TCP which worked great, but the performance
hit was too great.

These error accumulations now are much more rare with 2.4.20, however they
still exist and performance is still not what it should be. Also, we really
would prefer to run current release-quality kernel revs.

Does anyone have any suggestions as to what to try next?

--
Tim Wesemann


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs