2.6.29+ NFS-Server Problem "reconnect_path: npd != pd"
Sven Geggus
starting from Kernel 2.6.29.x (x=0 to 4) I get hundreds of the
following messages on my NFS-Server:
reconnect_path: npd != pd
The system works fine using 2.6.27.x
Unfortunatele the message is not harmless, because the client gets stale
NFS handles which is especially troublesome on diskless Workstations
using NFS root.
Regards
Sven
P.S.: The userland in use is Debian stable (lenny).
--
The main thing to note is that when you choose open source you don't
get a Windows operating system.
(from http://www.dell.com/ubuntu)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Trond Myklebust
> Hello,
>
> starting from Kernel 2.6.29.x (x=0 to 4) I get hundreds of the
> following messages on my NFS-Server:
>
> reconnect_path: npd != pd
>
> The system works fine using 2.6.27.x
>
> Unfortunatele the message is not harmless, because the client gets stale
> NFS handles which is especially troublesome on diskless Workstations
> using NFS root.
>
> Regards
>
> Sven
>
> P.S.: The userland in use is Debian stable (lenny).
I can't find any such error message in the kernel. Is this the userland
NFS server? If so, then this is the wrong list...
Trond
Sven Geggus
> I can't find any such error message in the kernel.
The message seems to come from fs/exportfs/expfs.c
> Is this the userland NFS server?
No, its not!
Sven
--
If we want hardware to work to its full potential, we need to claim to
be a recent version of Windows. (Matthew Garrett)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web
Trond Myklebust
> Trond Myklebust schrieb am Donnerstag, den 21. Mai um 18:49 Uhr:
>
> > I can't find any such error message in the kernel.
>
> The message seems to come from fs/exportfs/expfs.c
>
> > Is this the userland NFS server?
>
> No, its not!
>
> Sven
So what is the underlying filesystem that you are exporting, and what
does your /etc/exports file look like?
Trond
Sven Geggus
> So what is the underlying filesystem that you are exporting, and what
> does your /etc/exports file look like?
The underlying filesystem is xfs and /etc/exports (unchanged) is here:
--cut--
# /etc/exports: the access control list for filesystems which may be exported
# to NFS clients. See exports(5).
/ 192.168.3.2(rw,no_root_squash,async,subtree_check)
/home/sven 192.168.3.2(rw,no_root_squash,async,subtree_check) 192.168.3.6(rw,no_root_squash,async,subtree_check) 192.168.3.8(rw,no_root_squash,async,subtree_check)
/home/mp3 192.168.3.2(rw,no_root_squash,async,subtree_check) 192.168.3.6(rw,no_root_squash,async,subtree_check) 192.168.3.8(rw,no_root_squash,async,subtree_check)
/home/sven/filme 192.168.3.7(ro,async,subtree_check)
/home/kathi910 192.168.3.7(rw,no_root_squash,async,no_subtree_check)
--cut--
192.168.3.2 is the client which causes the error, I didn't notice the
error on the other clients, but they are not used that often.
Especially 192.168.3.7 does seem to work.
Regards
Sven
--
"We don't know the OS that God uses, but the Vatican uses Linux"
(Sister Judith Zoebelein, Vatican Webmaster)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web
Trond Myklebust
> Trond Myklebust <trond.m...@fys.uio.no> wrote:
>
> > So what is the underlying filesystem that you are exporting, and what
> > does your /etc/exports file look like?
>
> The underlying filesystem is xfs and /etc/exports (unchanged) is here:
>
> --cut--
> # /etc/exports: the access control list for filesystems which may be exported
> # to NFS clients. See exports(5).
> / 192.168.3.2(rw,no_root_squash,async,subtree_check)
> /home/sven 192.168.3.2(rw,no_root_squash,async,subtree_check) 192.168.3.6(rw,no_root_squash,async,subtree_check) 192.168.3.8(rw,no_root_squash,async,subtree_check)
> /home/mp3 192.168.3.2(rw,no_root_squash,async,subtree_check) 192.168.3.6(rw,no_root_squash,async,subtree_check) 192.168.3.8(rw,no_root_squash,async,subtree_check)
> /home/sven/filme 192.168.3.7(ro,async,subtree_check)
> /home/kathi910 192.168.3.7(rw,no_root_squash,async,no_subtree_check)
> --cut--
>
> 192.168.3.2 is the client which causes the error, I didn't notice the
> error on the other clients, but they are not used that often.
>
> Especially 192.168.3.7 does seem to work.
>
> Regards
>
> Sven
>
Reforwarding the reply for the benefit of the NFS mailing list. Not
everyone reads lkml...
Trond
J. Bruce Fields
> On Thu, 2009-05-21 at 17:48 +0000, Sven Geggus wrote:
> > Trond Myklebust <trond.m...@fys.uio.no> wrote:
> >
> > > So what is the underlying filesystem that you are exporting, and what
> > > does your /etc/exports file look like?
> >
> > The underlying filesystem is xfs and /etc/exports (unchanged) is here:
> >
> > --cut--
> > # /etc/exports: the access control list for filesystems which may be exported
> > # to NFS clients. See exports(5).
> > / 192.168.3.2(rw,no_root_squash,async,subtree_check)
> > /home/sven 192.168.3.2(rw,no_root_squash,async,subtree_check) 192.168.3.6(rw,no_root_squash,async,subtree_check) 192.168.3.8(rw,no_root_squash,async,subtree_check)
> > /home/mp3 192.168.3.2(rw,no_root_squash,async,subtree_check) 192.168.3.6(rw,no_root_squash,async,subtree_check) 192.168.3.8(rw,no_root_squash,async,subtree_check)
> > /home/sven/filme 192.168.3.7(ro,async,subtree_check)
> > /home/kathi910 192.168.3.7(rw,no_root_squash,async,no_subtree_check)
> > --cut--
> >
> > 192.168.3.2 is the client which causes the error, I didn't notice the
> > error on the other clients, but they are not used that often.
> >
> > Especially 192.168.3.7 does seem to work.
> >
> > Regards
> >
> > Sven
> >
>
> Reforwarding the reply for the benefit of the NFS mailing list. Not
> everyone reads lkml...
Original thread starts here:
http://marc.info/?l=linux-kernel&m=124291571326139&w=2
I don't think this is a known bug.
Looks like you have subtree_check set on the "bad" export, and
no_subtree_check set on the "good" export. subtree_check can result in
spurious stale errors when files are renamed, so it's possible this is
by design.
You say you get that message on 296.29.x but not 2.6.27.x. And you say
you also get stale filehandle errors. I assume you didn't get the same
stale filehandle errors on 2.6.27.x?
--b.
Sven Geggus
> Looks like you have subtree_check set on the "bad" export, and
> no_subtree_check set on the "good" export. subtree_check can result in
> spurious stale errors when files are renamed, so it's possible this is
> by design.
>
> You say you get that message on 296.29.x but not 2.6.27.x.
Exactly! http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=527517
may refer the same bug.
> And you say you also get stale filehandle errors.
Only on 2.6.29.x. Everything works fine qwith the older Kernel.
> I assume you didn't get the same stale filehandle errors on 2.6.27.x?
No errors on the older Kernel.
Sven
--
"In my opinion MS is a lot better at making money than it is at making good
operating systems" (Linus Torvalds, August 1997)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web
Sven Geggus
> For a while my server has been running fine after the upgrade to 2.6.30.
> My NFS/diskless desktop worked just fine. Then yesterday evening suddenly the
> first "reconnect_path: npd != pd" messages popped up. Sometime during the
> night the frequency of those messages showing up increased to > 100 msgs/sec
> in average.
More or less the same here. My client machine (2.6.30) however worked just
for a few hours. It does however work fine using the older Kernel (2.6.27.x)
on the Server.
This is also XFS+NFS here. I will also attach the associated .config of the
Kernel.
Regards
Sven
--
"Those who do not understand Unix are condemned to reinvent it, poorly"
(Henry Spencer)
Mathias Kretschmer
I'd like to confirm that this issue still exists with 2.6.30.
For a while my server has been running fine after the upgrade to 2.6.30.
My NFS/diskless desktop worked just fine. Then yesterday evening suddenly the
first "reconnect_path: npd != pd" messages popped up. Sometime during the
night the frequency of those messages showing up increased to > 100 msgs/sec
in average.
On my desktop I got a few 'stale NFS handles'. The most prominent one
being '/etc'. Needless to say, NFS is completely useless for me right now.
The desktop has been running various 2.6.30-rc kernels and is now also on
2.6.30 vanilla.
The messages started to show up when I upgraded the server from 2.6.25 to
2.6.29 (and now to .30).
The underlaying filesystem on the server is XFS (sata/raid6/lvm/xfs).
This is an x86_64 kernel.
I've ported my .config forward manually using 'make oldconfig' by saying 'yes'
to options that seemed reasonable to me.
As reported on the other thread regarding NFS + XFS, I did not experience any
kernel crashes with 2.6.30 anymore.
My .config is attached.
Any further info I can provide ?
Cheers,
Mathias
Thomas Petersen
Hash: SHA1
Sven Geggus wrote:
> Trond Myklebust <trond.m...@fys.uio.no> wrote:
>
>> So what is the underlying filesystem that you are exporting, and what
>> does your /etc/exports file look like?
>
> The underlying filesystem is xfs and /etc/exports (unchanged) is here:
>
> --cut--
> /home/sven 192.168.3.2(rw,no_root_squash,async,subtree_check) 192.168.3.6(rw,no_root_squash,async,subtree_check) 192.168.3.8(rw,no_root_squash,async,subtree_check)
I switched to 2.6.29 on my server yesterday. It seemed to work fine but
a few hours ago I began to get the same errors (reconnect_path: npd != pd).
I have a diskless client which received stale nfs handles and stopped
working properly. I have a laptop also which is still working ok but
that client doesn't utilize the nfs filesystems that much.
I'm using gentoo on all computers. Both clients are using 2.6.28. Server
switched from 2.6.27 to 2.6.29.
I am using XFS on the server !
There is a special thing about the server though and until I saw this
discussion I thought that was the problem:
I updated the kernel because I also replaced the hardware (except the
harddrives). I switched from an old AMD Athlon (32 bit) to an AMD Phenom
II (64 bit, 4 cores). The new kernel is compiled in 64 bit but all
userland is still the old 32 bit compiled on the old Athlon. Everything
runs through IA32 emulation.
Both clients are 32 bit machines.
In a few days I'll start to update to 64 bit userland on the server and
see if that has an effect on the problem.
Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAko/4boACgkQOaC6N60T7rze2gCfVRHI6H5hzyC4eX80H2hywJ81
3/QAnA17/9MEO3Zm8eosOtfzU+q3sYi6
=fgT+
-----END PGP SIGNATURE-----
Leandro Lucarella
> Mathias Kretschmer schrieb am Freitag, den 19. Juni um 14:14 Uhr:
>
> > For a while my server has been running fine after the upgrade to 2.6.30.
> > My NFS/diskless desktop worked just fine. Then yesterday evening suddenly the
> > first "reconnect_path: npd != pd" messages popped up. Sometime during the
> > night the frequency of those messages showing up increased to > 100 msgs/sec
> > in average.
>
> More or less the same here. My client machine (2.6.30) however worked just
> for a few hours. It does however work fine using the older Kernel (2.6.27.x)
> on the Server.
>
> This is also XFS+NFS here. I will also attach the associated .config of the
> Kernel.
Hi, I want to confirm that I'm still having this problem in 2.6.30. I'm
using Debian (unstable) too, and the exported fs is XFS.
Here is a related bug report:
http://bugzilla.kernel.org/show_bug.cgi?id=13375
--
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)