Oren Held | 1 Nov 16:34 2003
Picon

try tcp first; then udp

Hi,

I wonder if there's a way to mount an nfs share without specifying tcp
or udp mount. I think that this is how Solaris behaves: it tries first
tcp, if it's not good, then it tries udp.

I've been looking for such a mount option and found none; I think it can
be really useful when one has hetrogenous nfs servers (some use tcp,
some use udp) - in the case I just want it to work and don't care which
protocol it'll use.

Is there a way to do it with the current kernel/mount versions?

10x

 - Oren

-------------------------------------------------------
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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Marc Schmitt | 2 Nov 15:20 2003
Picon

bad cookie size 20 (only cookies under 8 bytes are supported.)

Hi all,

I did upgrade yesterday my RedHat 7.3 box (2.4.20-20.7smp) from 
nfs-utils 1.0.5 to 1.0.6, after that, messages was full with:

Nov  2 15:02:56 server kernel: lockd: bad cookie size 20 (only cookies 
under 8 bytes are supported.)
Nov  2 15:02:56 server kernel: svc: failed to decode args
Nov  2 15:02:57 server kernel: lockd: bad cookie size 20 (only cookies 
under 8 bytes are supported.)
Nov  2 15:02:57 server kernel: svc: failed to decode args
Nov  2 15:03:16 server kernel: lockd: bad cookie size 20 (only cookies 
under 8 bytes are supported.)

I've never had those messages before, does 1.0.6 require a certain 
minimum kernel version (ex. >= 2.4.22)?

TIA

Regards,
    Marc

-------------------------------------------------------
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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
(Continue reading)

Marc Schmitt | 2 Nov 18:22 2003
Picon

Re: bad cookie size 20 (only cookies under 8 bytes are supported.)

Just wanted to add:
On the same token, I did have to move the exported files to a different 
partition. Before I did that, I asked all users to log out everywhere, 
so that no homes are mounted before I started moving the files. Could it 
be that this errors come from clients that try to lock "old" inodes?

Marc Schmitt wrote:

> Hi all,
>
> I did upgrade yesterday my RedHat 7.3 box (2.4.20-20.7smp) from 
> nfs-utils 1.0.5 to 1.0.6, after that, messages was full with:
>
> Nov  2 15:02:56 server kernel: lockd: bad cookie size 20 (only cookies 
> under 8 bytes are supported.)
> Nov  2 15:02:56 server kernel: svc: failed to decode args
> Nov  2 15:02:57 server kernel: lockd: bad cookie size 20 (only cookies 
> under 8 bytes are supported.)
> Nov  2 15:02:57 server kernel: svc: failed to decode args
> Nov  2 15:03:16 server kernel: lockd: bad cookie size 20 (only cookies 
> under 8 bytes are supported.)

-------------------------------------------------------
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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
(Continue reading)

James Pearson | 3 Nov 13:01 2003

Re: try tcp first; then udp

I asked this question a little why ago - Trond Myklebust has a patch
that does lots of other things, but can be easily modified to try tcp
first, then udp (by default his patch does udp first) see:

http://marc.theaimsgroup.com/?l=linux-nfs&m=105111029228592&w=2

I had to make a couple of other changes to the patch to get it to
compile with the RedHat version of the mount (util-linux) source RPM I'm
using - I've put my modified patch at:

ftp://ftp.moving-picture/private/james/util-linux-2.11n-tcpmount.patch.gz

I also had a minor problem on older RH7.1 machines that also need the
following patch:

ftp://ftp.moving-picture/private/james/util-linux-2.11n-cbuf.patch.gz

I've been using this modified mount for a few months without problems.

James Pearson

Oren Held wrote:
> 
> Hi,
> 
> I wonder if there's a way to mount an nfs share without specifying tcp
> or udp mount. I think that this is how Solaris behaves: it tries first
> tcp, if it's not good, then it tries udp.
> 
> I've been looking for such a mount option and found none; I think it can
(Continue reading)

Lever, Charles | 3 Nov 16:18 2003
Picon

RE: nfs client's local cache

hi robert-

> An NFS client machine has several processes that open a file on a NFS
> server read-only for quite a long time (server processes).
> 
> The file gets replaced on the NFS server.
> 
> The client processes still have the old copy open.
> 
> A new process on the NFS client also only sees the old copy of that
> file. Only after the running processes are killed or close() the
> filehandle and the filesystems gets remounted the NFS client machine
> sees the new version of that file.
> 
> Is that expected behaviour? Is there any local NFS client 
> cache timeout involved?

there are three effects in play here:

1.  close-to-open cache coherency
2.  weak cache consistency
3.  attribute cache timeout

i suspect you are using NFSv2 on an older 2.4 kernel.  can you provide
your mount options via "cat /proc/mount" and the output of "uname -a" ?

-------------------------------------------------------
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
(Continue reading)

Robert Sander | 3 Nov 16:46 2003

Re: nfs client's local cache

On Mon, 3 Nov 2003 15:36:27 +0000 (UTC),
 "Lever, Charles" <Charles.Lever <at> netapp.com> wrote:
> there are three effects in play here:
> 
> 1.  close-to-open cache coherency
> 2.  weak cache consistency
> 3.  attribute cache timeout
> 
> i suspect you are using NFSv2 on an older 2.4 kernel.  can you provide
> your mount options via "cat /proc/mount" and the output of "uname -a" ?

Hi!

This happened independently on two NFS-Servers with several clients.

1. NFS-Server: 2.4.20 running kernel-nfsd
   Client: 2.4.19-64GB-SMP (SuSE SLES)
           /proc/mounts: rw,v3,rsize=4096,wsize=4096,hard,intr,udp,nolock
   Client: 2.4.20
                         rw,v3,rsize=8192,wsize=8192,hard,intr,udp,nolock

2. NFS-Server: 2.4.20 running userspace-nfsd
   Client: 2.4.19-64GB-SMP (SuSE SLES)
                         ro,v2,rsize=4096,wsize=4096,hard,intr,udp,nolock

The second combination obviously runs NFSv2 but we had that effect with
the first combination and NFSv3, too.

Greetings
--

-- 
(Continue reading)

Timothy G. Wesemann | 3 Nov 23:35 2003

nfs: server X not responding, still trying

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
(Continue reading)

martinnitram@excite.com | 4 Nov 02:46 2003
Picon

can't reexport NCP mount point by NFS


Dear all,

at past, we had a Redhat 6.0 (kernel 2.2.5-15, knfsd-

1.2.2-4, ncpfs-2.2.0.12) that using ncpmount to mount 

Netware File server and use nfsd to re-export it and let 

other linux machine to mount it, everything work fine.

Currently, we planned to upgrade this machine to RH 

7.3 (clearly installed, with all update, ncpfs-2.2.0.18-

133.i386.rpm, ), Netware mount and local file system 

export ok, but fail when reexport the mounted Netware 

volume, and message log shown:

getfh failed: Operation not permitted

From the document (How-To, README), it claimed that 

need to reload the mountd/nfsd by --re-export options 

after volume mounted (we had use -V option at 

ncpmount already). But from manpage of mounted/nfsd, 
(Continue reading)

Martin Spott | 1 Nov 17:29 2003
Picon

Re: 2.6.0-test3-bk10-final regression getting out of hand

Voluspa <lista2 <at> comhem.se> wrote:

> I'm experiencing a serious NFS regression since 2.6.0-test3-bk10-final
> (bk-set determined now). Since that, along the road to 2.6.0-test9,
> something has gotten completely out of hand.

I can second the experiences on heavy trouble with 2.6.0-test[8,9] as
NFS _client_ against 2.4.2[1,2] as a server. I didn't have different
servers for testing against but I pretty much _believe_ it's a client
issue.

I only sticked to 'official' 2.6.0-test patches and I'd like to
express, that beginning with 2.6.0-test8 the NFS client is absolutely
unsuable for me. Trying to copy (with 'cp') a file from a local
filesystem to the server over NFS.V2 or .V3 completely freezes _any_
NFS traffic with the same server.
Are there any significant changes to the NFS client I should back out
for the purpose of finding the 'bug' ?

Martin.
--

-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

-------------------------------------------------------
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/
_______________________________________________
(Continue reading)

Trond Myklebust | 4 Nov 07:35 2003
Picon
Picon

Re: 2.6.0-test3-bk10-final regression getting out of hand

>>>>> " " == Martin Spott <Martin.Spott <at> uni-duisburg.de> writes:

     > completely freezes _any_ NFS traffic with the same server.  Are
     > there any significant changes to the NFS client I should back
     > out for the purpose of finding the 'bug' ?

Err... If you believe it is the client, they I suggest backing out
_all_ client related patches between test7 and test8 for a start...

Personally, I'm starting to suspect some of the IPv4 changes. I'm
seeing wierd crap with the TCP code which suggests some form of memory
corruption. The corruption is occurring on both the client *and*
server side.
The fact that I'm seeing signs of memory poisoning suggests it is
probably an skb being freed too early or something like that.

Cheers,
  Trond

-------------------------------------------------------
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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs


Gmane