From mboxrd@z Thu Jan 1 00:00:00 1970 From: Subject: Problem with NLM on Fedora Date: Tue, 12 Apr 2005 21:55:32 +0100 Message-ID: <9E621559095AA746B22B21CD4FAF99A50A4E76@EDINMAIL1.ad.datcon.co.uk> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C53FA1.F7B9DD90" Return-path: Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.12] helo=sc8-sf-mx2.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 4.30) id 1DLSQ9-0007x5-Dg for nfs@lists.sourceforge.net; Tue, 12 Apr 2005 13:55:41 -0700 Received: from smtp.dataconnection.com ([192.91.191.4]) by sc8-sf-mx2.sourceforge.net with esmtp (Exim 4.41) id 1DLSQ8-0004Db-Af for nfs@lists.sourceforge.net; Tue, 12 Apr 2005 13:55:41 -0700 To: Sender: nfs-admin@lists.sourceforge.net Errors-To: nfs-admin@lists.sourceforge.net List-Unsubscribe: , List-Id: Discussion of NFS under Linux development, interoperability, and testing. List-Post: List-Help: List-Subscribe: , List-Archive: This is a multi-part message in MIME format. ------_=_NextPart_001_01C53FA1.F7B9DD90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > I've just installed Fedora, and am having problems with NFS. =20 >=20 > What I'm seeing is that NLM requests are not issued to the NFS server = (which is a SNAP Server). Instead the application hangs for about 7 = seconds, and then returns successfully (i.e. the locks are ostensibly = granted). The delay happens both on locks and unlock requests. Via = tcpdump I see NFS requests/responses, but no RPC calls for NLM. >=20 > Here's what uname -a says about my system. >=20 > Linux rack10.datcon.co.uk 2.6.9-1.667smp #1 SMP Tue Nov 2 14:59:52 EST = 2004 i686 i686 i386 GNU/Linux >=20 > Here's the mount point >=20 > 172.19.15.109:/mngdata/keepalive on /opt/dcl/keepalive type nfs = (rw,rsize=3D4096,wsize=3D4096,hard,intr,bg,lock,nfsvers=3D3,addr=3D172.19= .15.109) >=20 > pstack shows I'm hung here: >=20 > 0x002447a2: _dl_sysinfo_int80 + 0x2 (b, e, fefe2080, 0, 0, 0) + 1400 >=20 > I downloaded nfsutils 1.0.7, but that didn't help. I also saw this: >=20 > A. There are permisions on the /var/lib/nfs/sm and /var/lib/nfs/sm.bak = files that must be addressed. Whomever rpc.statd is running as must have = ownership and rw access to those dirs. The permissions should be set to = 700 for both. In addition, etab, rmtab, and xtab all must exist and be = writable by root. >=20 > So I tried changing the permissions: >=20 > /var/lib/nfs: > total 32 > -rwxrwxrwx 1 root root 0 Apr 12 11:58 etab > -rwxrwxrwx 1 root root 0 Apr 12 11:58 rmtab > drwxr-xr-x 7 root root 0 Apr 12 12:29 rpc_pipefs > drwx------ 2 root root 4096 Apr 12 11:58 sm > drwx------ 2 root root 4096 Apr 12 11:58 sm.bak > drwxrwxrwx 4 root root 4096 Apr 12 06:28 statd > -rwxrwxrwx 1 root root 0 Apr 12 11:58 state > -rwxrwxrwx 1 root root 0 Apr 12 11:58 xtab >=20 > /var/lib/nfs/statd: > total 12 > drwxrwxrwx 2 root root 4096 Apr 12 12:31 sm > drwxrwxrwx 2 root root 4096 Apr 12 12:29 sm.bak > -rwxrwxrwx 1 root root 4 Apr 12 12:29 state >=20 > ...and I've rebooted. None of this has helped. >=20 > Any suggestions? >=20 > Edward. ------_=_NextPart_001_01C53FA1.F7B9DD90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Problem with NLM on Fedora

I've just installed = Fedora, and am having problems with NFS. 

What I'm seeing is = that NLM requests are not issued to the NFS server (which is a SNAP = Server).  Instead the application hangs for about 7 seconds, and = then returns successfully (i.e. the locks are ostensibly granted).  = The delay happens both on locks and unlock requests.  Via tcpdump I = see NFS requests/responses, but no RPC calls for NLM.

Here's what uname -a = says about my system.

Linux = rack10.datcon.co.uk 2.6.9-1.667smp #1 SMP Tue Nov 2 14:59:52 EST 2004 = i686 i686 i386 GNU/Linux

Here's the mount = point

172.19.15.109:/mngdata/keepalive on /opt/dcl/keepalive = type nfs = (rw,rsize=3D4096,wsize=3D4096,hard,intr,bg,lock,nfsvers=3D3,addr=3D172.19= .15.109)

pstack shows I'm hung = here:

0x002447a2: = _dl_sysinfo_int80 + 0x2 (b, e, fefe2080, 0, 0, 0) + 1400

I downloaded nfsutils = 1.0.7, but that didn't help.  I also saw this:

A. There are permisions on the /var/lib/nfs/sm and /var/lib/nfs/sm.bak files = that must be addressed. Whomever rpc.statd is running as must have = ownership and rw access to those dirs. The permissions should be set to = 700 for both. In addition, etab, rmtab, and xtab all must exist and be = writable by root.

So I tried changing = the permissions:

/var/lib/nfs:
total 32
-rwxrwxrwx  1 = root root    0 Apr 12 11:58 etab
-rwxrwxrwx  1 = root root    0 Apr 12 11:58 rmtab
drwxr-xr-x  7 = root root    0 Apr 12 12:29 rpc_pipefs
drwx------  2 = root root 4096 Apr 12 11:58 sm
drwx------  2 = root root 4096 Apr 12 11:58 sm.bak
drwxrwxrwx  4 = root root 4096 Apr 12 06:28 statd
-rwxrwxrwx  1 = root root    0 Apr 12 11:58 state
-rwxrwxrwx  1 = root root    0 Apr 12 11:58 xtab

/var/lib/nfs/statd:
total 12
drwxrwxrwx  2 = root root 4096 Apr 12 12:31 sm
drwxrwxrwx  2 = root root 4096 Apr 12 12:29 sm.bak
-rwxrwxrwx  1 = root root    4 Apr 12 12:29 state

...and I've = rebooted.  None of this has helped.

Any = suggestions?

Edward.

------_=_NextPart_001_01C53FA1.F7B9DD90-- ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Dickson Subject: Re: Problem with NLM on Fedora Date: Wed, 13 Apr 2005 19:43:55 -0400 Message-ID: <425DAEBB.2000806@RedHat.com> References: <9E621559095AA746B22B21CD4FAF99A50A4E76@EDINMAIL1.ad.datcon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Cc: nfs@lists.sourceforge.net Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.11] helo=sc8-sf-mx1.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 4.30) id 1DLrWk-0007Ft-Oe for nfs@lists.sourceforge.net; Wed, 13 Apr 2005 16:44:10 -0700 Received: from mx1.redhat.com ([66.187.233.31]) by sc8-sf-mx1.sourceforge.net with esmtp (TLSv1:AES256-SHA:256) (Exim 4.41) id 1DLrWe-00029v-SW for nfs@lists.sourceforge.net; Wed, 13 Apr 2005 16:44:10 -0700 To: eh@dataconnection.com In-Reply-To: <9E621559095AA746B22B21CD4FAF99A50A4E76@EDINMAIL1.ad.datcon.co.uk> Sender: nfs-admin@lists.sourceforge.net Errors-To: nfs-admin@lists.sourceforge.net List-Unsubscribe: , List-Id: Discussion of NFS under Linux development, interoperability, and testing. List-Post: List-Help: List-Subscribe: , List-Archive: eh@dataconnection.com wrote: > I've just installed Fedora, and am having problems with NFS. > > What I'm seeing is that NLM requests are not issued to the NFS server > (which is a SNAP Server). Instead the application hangs for about 7 > seconds, and then returns successfully (i.e. the locks are ostensibly > granted). The delay happens both on locks and unlock requests. Via > tcpdump I see NFS requests/responses, but no RPC calls for NLM. Could you post a bzip2-ed ethereal trace (meaning tethereal -w /tmp/dump.pcap; bzip2 /tmp/dump.pcap) of this? There are some know locking issue with FC3 (see: https://bugzilla.redhat.com/beta/show_bug.cgi?id=150151) but this appears to be a bit different... steved. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs From mboxrd@z Thu Jan 1 00:00:00 1970 From: Subject: RE: Problem with NLM on Fedora Date: Thu, 14 Apr 2005 11:05:51 +0100 Message-ID: <9E621559095AA746B22B21CD4FAF99A50A4EEC@EDINMAIL1.datcon.co.uk> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C540D9.89B02ACA" Cc: Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.11] helo=sc8-sf-mx1.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 4.30) id 1DM1EX-000679-Co for nfs@lists.sourceforge.net; Thu, 14 Apr 2005 03:06:01 -0700 Received: from smtp.dataconnection.com ([192.91.191.4]) by sc8-sf-mx1.sourceforge.net with esmtp (Exim 4.41) id 1DM1EV-00061z-Jl for nfs@lists.sourceforge.net; Thu, 14 Apr 2005 03:06:01 -0700 To: "Steve Dickson" Sender: nfs-admin@lists.sourceforge.net Errors-To: nfs-admin@lists.sourceforge.net List-Unsubscribe: , List-Id: Discussion of NFS under Linux development, interoperability, and testing. List-Post: List-Help: List-Subscribe: , List-Archive: This is a multi-part message in MIME format. ------_=_NextPart_001_01C540D9.89B02ACA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Digging a bit deeper, I was wrong to say there are no NLM packets = flowing. Sorry. What I think is happening is that the NLM requests are being lost, and = the delays I'm seeing are due to retransmission. One difference that I = notice from tcpdump trace is that Fedora is using TCP connections for = the NLM traffic, whereas RedHat 8 (running successfully against the same = filer) is using UDP. Although I'd expect TCP to be more reliable, it's possible that the = filer isn't very good at TCP traffic. TCP support has recently been = added to this SNAP model - it only used to use UDP. So maybe it's = flakey. Is it possible to force the NLM traffic over UDP from the client side? Edward. -----Original Message----- From: Steve Dickson [ = mailto:SteveD@redhat.com] Sent: 14 April 2005 00:44 To: Edward Hibbert (eh@dataconnection.com) Cc: nfs@lists.sourceforge.net Subject: Re: [NFS] Problem with NLM on Fedora eh@dataconnection.com wrote: > I've just installed Fedora, and am having problems with NFS. > > What I'm seeing is that NLM requests are not issued to the NFS server > (which is a SNAP Server). Instead the application hangs for about 7 > seconds, and then returns successfully (i.e. the locks are ostensibly > granted). The delay happens both on locks and unlock requests. Via > tcpdump I see NFS requests/responses, but no RPC calls for NLM. Could you post a bzip2-ed ethereal trace (meaning tethereal -w /tmp/dump.pcap; bzip2 /tmp/dump.pcap) of this? There are some know locking issue with FC3 (see: = https://bugzilla.redhat.com/beta/show_bug.cgi?id=3D150151) but this appears to be a bit different... steved. ------_=_NextPart_001_01C540D9.89B02ACA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Digging a bit = deeper, I was wrong=20 to say there are no NLM packets flowing.  Sorry.

What I think is happening = is that the=20 NLM requests are being lost, and the delays I'm seeing are due to=20 retransmission.  One difference that I notice from tcpdump trace is = that=20 Fedora is using TCP connections for the NLM traffic, whereas RedHat 8 = (running=20 successfully against the same filer) is using UDP.

Although I'd expect TCP = to be more=20 reliable, it's possible that the filer isn't very good at TCP=20 traffic.  TCP support has recently been added to this = SNAP model=20 - it only used to use UDP.  So maybe it's flakey.

Is it possible to force = the NLM traffic=20 over UDP from the client side?

Edward.


-----Original=20 Message-----
From: Steve Dickson [
mailto:SteveD@redhat.com]
Sent: 14 = April 2005=20 00:44
To: Edward Hibbert (eh@dataconnection.com)
Cc:=20 nfs@lists.sourceforge.net
Subject: Re: [NFS] Problem with NLM on=20 Fedora


eh@dataconnection.com wrote:
> I've just = installed=20 Fedora, and am having problems with NFS.
>
> What I'm seeing = is that=20 NLM requests are not issued to the NFS server
> (which is a SNAP=20 Server).  Instead the application hangs for about 7
> = seconds, and=20 then returns successfully (i.e. the locks are ostensibly
> = granted). =20 The delay happens both on locks and unlock requests.  Via
> = tcpdump I=20 see NFS requests/responses, but no RPC calls for NLM.
Could you post = a=20 bzip2-ed ethereal trace (meaning
tethereal -w /tmp/dump.pcap; bzip2=20 /tmp/dump.pcap) of this?

There are some know locking issue with=20 FC3
(see:
https://bugzilla.redhat.com/beta/show_bug.cgi?id=3D150151= )
but this appears to be a bit=20 different...

steved.

------_=_NextPart_001_01C540D9.89B02ACA-- ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs From mboxrd@z Thu Jan 1 00:00:00 1970 From: Subject: RE: Problem with NLM on Fedora Date: Thu, 14 Apr 2005 11:51:29 +0100 Message-ID: <9E621559095AA746B22B21CD4FAF99A50A4EF1@EDINMAIL1.datcon.co.uk> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C540DF.E99BC627" Cc: Return-path: Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.12] helo=sc8-sf-mx2.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 4.30) id 1DM1wf-0008UL-TY for nfs@lists.sourceforge.net; Thu, 14 Apr 2005 03:51:37 -0700 Received: from smtp2.dataconnection.com ([192.91.191.8]) by sc8-sf-mx2.sourceforge.net with esmtp (Exim 4.41) id 1DM1wc-0001hj-Vc for nfs@lists.sourceforge.net; Thu, 14 Apr 2005 03:51:37 -0700 To: "Steve Dickson" Sender: nfs-admin@lists.sourceforge.net Errors-To: nfs-admin@lists.sourceforge.net List-Unsubscribe: , List-Id: Discussion of NFS under Linux development, interoperability, and testing. List-Post: List-Help: List-Subscribe: , List-Archive: This is a multi-part message in MIME format. ------_=_NextPart_001_01C540DF.E99BC627 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Moving my data onto a filer which doesn't expose TCP (and therefore = forces use of UDP) seems to work fine. =20 So I'm now convinced this isn't a client-side problem. However I need = to work with this particular server, so to work around the server-side = problem, I'd still like a way to force NLM connections to use UDP rather = than TCP. =20 =20 Anyone know how to do this? =20 Edward. -----Original Message----- From: Edward Hibbert (eh@dataconnection.com)=20 Sent: 14 April 2005 11:06 To: 'Steve Dickson' Cc: nfs@lists.sourceforge.net Subject: RE: [NFS] Problem with NLM on Fedora Digging a bit deeper, I was wrong to say there are no NLM packets = flowing. Sorry. What I think is happening is that the NLM requests are being lost, and = the delays I'm seeing are due to retransmission. One difference that I = notice from tcpdump trace is that Fedora is using TCP connections for = the NLM traffic, whereas RedHat 8 (running successfully against the same = filer) is using UDP. Although I'd expect TCP to be more reliable, it's possible that the = filer isn't very good at TCP traffic. TCP support has recently been = added to this SNAP model - it only used to use UDP. So maybe it's = flakey. Is it possible to force the NLM traffic over UDP from the client side? Edward. -----Original Message----- From: Steve Dickson [ = mailto:SteveD@redhat.com] Sent: 14 April 2005 00:44 To: Edward Hibbert (eh@dataconnection.com) Cc: nfs@lists.sourceforge.net Subject: Re: [NFS] Problem with NLM on Fedora eh@dataconnection.com wrote: > I've just installed Fedora, and am having problems with NFS. > > What I'm seeing is that NLM requests are not issued to the NFS server > (which is a SNAP Server). Instead the application hangs for about 7 > seconds, and then returns successfully (i.e. the locks are ostensibly > granted). The delay happens both on locks and unlock requests. Via > tcpdump I see NFS requests/responses, but no RPC calls for NLM. Could you post a bzip2-ed ethereal trace (meaning tethereal -w /tmp/dump.pcap; bzip2 /tmp/dump.pcap) of this? There are some know locking issue with FC3 (see: = https://bugzilla.redhat.com/beta/show_bug.cgi?id=3D150151) but this appears to be a bit different... steved. ------_=_NextPart_001_01C540DF.E99BC627 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Moving=20 my data onto a filer which doesn't expose TCP (and therefore forces use = of UDP)=20 seems to work fine.
 
So I'm=20 now convinced this isn't a client-side problem.  However I need to = work=20 with this particular server, so to work around the server-side problem, = I'd=20 still like a way to force NLM connections to use UDP rather than = TCP. =20
 
Anyone=20 know how to do this?
 
Edward.
-----Original Message-----
From: Edward Hibbert=20 (eh@dataconnection.com)
Sent: 14 April 2005 = 11:06
To:=20 'Steve Dickson'
Cc: = nfs@lists.sourceforge.net
Subject: RE:=20 [NFS] Problem with NLM on Fedora

Digging a bit = deeper, I was=20 wrong to say there are no NLM packets flowing.  = Sorry.

What I think is = happening is that the=20 NLM requests are being lost, and the delays I'm seeing are due to=20 retransmission.  One difference that I notice from tcpdump trace = is that=20 Fedora is using TCP connections for the NLM traffic, whereas RedHat 8 = (running=20 successfully against the same filer) is using UDP.

Although I'd expect TCP = to be more=20 reliable, it's possible that the filer isn't very good at TCP=20 traffic.  TCP support has recently been added to this = SNAP=20 model - it only used to use UDP.  So maybe it's = flakey.

Is it possible to force = the NLM=20 traffic over UDP from the client side?

Edward.


-----Original=20 Message-----
From: Steve Dickson [
mailto:SteveD@redhat.com]
Sent: = 14 April=20 2005 00:44
To: Edward Hibbert (eh@dataconnection.com)
Cc:=20 nfs@lists.sourceforge.net
Subject: Re: [NFS] Problem with NLM on=20 Fedora


eh@dataconnection.com wrote:
> I've just = installed=20 Fedora, and am having problems with NFS.
>
> What I'm = seeing is=20 that NLM requests are not issued to the NFS server
> (which is a = SNAP=20 Server).  Instead the application hangs for about 7
> = seconds, and=20 then returns successfully (i.e. the locks are ostensibly
>=20 granted).  The delay happens both on locks and unlock = requests. =20 Via
> tcpdump I see NFS requests/responses, but no RPC calls for = NLM.
Could you post a bzip2-ed ethereal trace (meaning
tethereal = -w=20 /tmp/dump.pcap; bzip2 /tmp/dump.pcap) of this?

There are some = know=20 locking issue with FC3
(see:
https://bugzilla.redhat.com/beta/show_bug.cgi?id=3D150151= )
but this appears to be a bit=20 different...

steved.

------_=_NextPart_001_01C540DF.E99BC627-- ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Edward Hibbert" Subject: Problem with NLM on Fedora Date: Tue, 12 Apr 2005 20:45:34 +0100 Message-ID: <9E621559095AA746B22B21CD4FAF99A50A4E6C@EDINMAIL1.ad.datcon.co.uk> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C53F98.310DF905" Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.11] helo=sc8-sf-mx1.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 4.30) id 1DLRKe-0004fC-MA for nfs@lists.sourceforge.net; Tue, 12 Apr 2005 12:45:56 -0700 Received: from smtp2.dataconnection.com ([192.91.191.8]) by sc8-sf-mx1.sourceforge.net with esmtp (Exim 4.41) id 1DLRKM-0003yT-Mq for nfs@lists.sourceforge.net; Tue, 12 Apr 2005 12:45:56 -0700 To: Sender: nfs-admin@lists.sourceforge.net Errors-To: nfs-admin@lists.sourceforge.net List-Unsubscribe: , List-Id: Discussion of NFS under Linux development, interoperability, and testing. List-Post: List-Help: List-Subscribe: , List-Archive: This is a multi-part message in MIME format. ------_=_NextPart_001_01C53F98.310DF905 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I've just installed Fedora, and am having problems with NFS. =20 What I'm seeing is that NLM requests are not issued to the NFS server = (which is a SNAP Server). Instead the application hangs for about 7 = seconds, and then returns successfully (i.e. the locks are ostensibly = granted). The delay happens both on locks and unlock requests. Via = tcpdump I see NFS requests/responses, but no RPC calls for NLM. Here's what uname -a says about my system. Linux rack10.datcon.co.uk 2.6.9-1.667smp #1 SMP Tue Nov 2 14:59:52 EST = 2004 i686 i686 i386 GNU/Linux Here's the mount point 172.19.15.109:/mngdata/keepalive on /opt/dcl/keepalive type nfs = (rw,rsize=3D4096,wsize=3D4096,hard,intr,bg,lock,nfsvers=3D3,addr=3D172.19= .15.109) pstack shows I'm hung here: 0x002447a2: _dl_sysinfo_int80 + 0x2 (b, e, fefe2080, 0, 0, 0) + 1400 I downloaded nfsutils 1.0.7, but that didn't help. I also saw this: A. There are permisions on the /var/lib/nfs/sm and /var/lib/nfs/sm.bak = files that must be addressed. Whomever rpc.statd is running as must have = ownership and rw access to those dirs. The permissions should be set to = 700 for both. In addition, etab, rmtab, and xtab all must exist and be = writable by root. So I tried changing the permissions: /var/lib/nfs: total 32 -rwxrwxrwx 1 root root 0 Apr 12 11:58 etab -rwxrwxrwx 1 root root 0 Apr 12 11:58 rmtab drwxr-xr-x 7 root root 0 Apr 12 12:29 rpc_pipefs drwx------ 2 root root 4096 Apr 12 11:58 sm drwx------ 2 root root 4096 Apr 12 11:58 sm.bak drwxrwxrwx 4 root root 4096 Apr 12 06:28 statd -rwxrwxrwx 1 root root 0 Apr 12 11:58 state -rwxrwxrwx 1 root root 0 Apr 12 11:58 xtab /var/lib/nfs/statd: total 12 drwxrwxrwx 2 root root 4096 Apr 12 12:31 sm drwxrwxrwx 2 root root 4096 Apr 12 12:29 sm.bak -rwxrwxrwx 1 root root 4 Apr 12 12:29 state ...and I've rebooted. None of this has helped. Any suggestions? Edward. ------_=_NextPart_001_01C53F98.310DF905 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Problem with NLM on Fedora

I've just installed = Fedora, and am having problems with NFS. 

What I'm seeing is = that NLM requests are not issued to the NFS server (which is a SNAP = Server).  Instead the application hangs for about 7 seconds, and = then returns successfully (i.e. the locks are ostensibly granted).  = The delay happens both on locks and unlock requests.  Via tcpdump I = see NFS requests/responses, but no RPC calls for NLM.

Here's what uname -a = says about my system.

Linux = rack10.datcon.co.uk 2.6.9-1.667smp #1 SMP Tue Nov 2 14:59:52 EST 2004 = i686 i686 i386 GNU/Linux

Here's the mount = point

172.19.15.109:/mngdata/keepalive on /opt/dcl/keepalive = type nfs = (rw,rsize=3D4096,wsize=3D4096,hard,intr,bg,lock,nfsvers=3D3,addr=3D172.19= .15.109)

pstack shows I'm hung = here:

0x002447a2: = _dl_sysinfo_int80 + 0x2 (b, e, fefe2080, 0, 0, 0) + 1400

I downloaded nfsutils = 1.0.7, but that didn't help.  I also saw this:

A. There are permisions on the /var/lib/nfs/sm and /var/lib/nfs/sm.bak files = that must be addressed. Whomever rpc.statd is running as must have = ownership and rw access to those dirs. The permissions should be set to = 700 for both. In addition, etab, rmtab, and xtab all must exist and be = writable by root.

So I tried changing = the permissions:

/var/lib/nfs:
total 32
-rwxrwxrwx  1 = root root    0 Apr 12 11:58 etab
-rwxrwxrwx  1 = root root    0 Apr 12 11:58 rmtab
drwxr-xr-x  7 = root root    0 Apr 12 12:29 rpc_pipefs
drwx------  2 = root root 4096 Apr 12 11:58 sm
drwx------  2 = root root 4096 Apr 12 11:58 sm.bak
drwxrwxrwx  4 = root root 4096 Apr 12 06:28 statd
-rwxrwxrwx  1 = root root    0 Apr 12 11:58 state
-rwxrwxrwx  1 = root root    0 Apr 12 11:58 xtab

/var/lib/nfs/statd:
total 12
drwxrwxrwx  2 = root root 4096 Apr 12 12:31 sm
drwxrwxrwx  2 = root root 4096 Apr 12 12:29 sm.bak
-rwxrwxrwx  1 = root root    4 Apr 12 12:29 state

...and I've = rebooted.  None of this has helped.

Any = suggestions?

Edward.

------_=_NextPart_001_01C53F98.310DF905-- ------------------------------------------------------- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neil Horman Subject: Re: Problem with NLM on Fedora Date: Wed, 20 Apr 2005 09:40:08 -0400 Message-ID: <20050420134008.GC8264@hmsendeavour.rdu.redhat.com> References: <9E621559095AA746B22B21CD4FAF99A50A4EF1@EDINMAIL1.datcon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Steve Dickson , nfs@lists.sourceforge.net Return-path: Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.12] helo=sc8-sf-mx2.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 4.30) id 1DOFR8-0000Rp-Ao for nfs@lists.sourceforge.net; Wed, 20 Apr 2005 06:40:14 -0700 Received: from mx1.redhat.com ([66.187.233.31]) by sc8-sf-mx2.sourceforge.net with esmtp (TLSv1:AES256-SHA:256) (Exim 4.41) id 1DOFR6-0008UV-Lf for nfs@lists.sourceforge.net; Wed, 20 Apr 2005 06:40:14 -0700 To: eh@dataconnection.com In-Reply-To: <9E621559095AA746B22B21CD4FAF99A50A4EF1@EDINMAIL1.datcon.co.uk> Sender: nfs-admin@lists.sourceforge.net Errors-To: nfs-admin@lists.sourceforge.net List-Unsubscribe: , List-Id: Discussion of NFS under Linux development, interoperability, and testing. List-Post: List-Help: List-Subscribe: , List-Archive: On Thu, Apr 14, 2005 at 11:51:29AM +0100, eh@dataconnection.com wrote: > Moving my data onto a filer which doesn't expose TCP (and therefore forces use of UDP) seems to work fine. > > So I'm now convinced this isn't a client-side problem. However I need to work with this particular server, so to work around the server-side problem, I'd still like a way to force NLM connections to use UDP rather than TCP. > > Anyone know how to do this? > > Edward. > > -----Original Message----- > From: Edward Hibbert (eh@dataconnection.com) > Sent: 14 April 2005 11:06 > To: 'Steve Dickson' > Cc: nfs@lists.sourceforge.net > Subject: RE: [NFS] Problem with NLM on Fedora > > > > Digging a bit deeper, I was wrong to say there are no NLM packets flowing. Sorry. > > What I think is happening is that the NLM requests are being lost, and the delays I'm seeing are due to retransmission. One difference that I notice from tcpdump trace is that Fedora is using TCP connections for the NLM traffic, whereas RedHat 8 (running successfully against the same filer) is using UDP. > > Although I'd expect TCP to be more reliable, it's possible that the filer isn't very good at TCP traffic. TCP support has recently been added to this SNAP model - it only used to use UDP. So maybe it's flakey. > > Is it possible to force the NLM traffic over UDP from the client side? > > Edward. > I think the NLM client mirrors whatever protocol the NFS client is using, so if you were to mount the NFS share with proto=udp in the mount options, NLM should also use udp, rather than tcp. Regards Neil > > -----Original Message----- > From: Steve Dickson [ mailto:SteveD@redhat.com] > Sent: 14 April 2005 00:44 > To: Edward Hibbert (eh@dataconnection.com) > Cc: nfs@lists.sourceforge.net > Subject: Re: [NFS] Problem with NLM on Fedora > > > eh@dataconnection.com wrote: > > I've just installed Fedora, and am having problems with NFS. > > > > What I'm seeing is that NLM requests are not issued to the NFS server > > (which is a SNAP Server). Instead the application hangs for about 7 > > seconds, and then returns successfully (i.e. the locks are ostensibly > > granted). The delay happens both on locks and unlock requests. Via > > tcpdump I see NFS requests/responses, but no RPC calls for NLM. > Could you post a bzip2-ed ethereal trace (meaning > tethereal -w /tmp/dump.pcap; bzip2 /tmp/dump.pcap) of this? > > There are some know locking issue with FC3 > (see: https://bugzilla.redhat.com/beta/show_bug.cgi?id=150151) > but this appears to be a bit different... > > steved. > > -- /*************************************************** *Neil Horman *Software Engineer *Red Hat, Inc. *nhorman@redhat.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ ------------------------------------------------------- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs