On Thu, May 21, 2009 at 02:12:26PM -0400, Trond Myklebust wrote:
> On Thu, 2009-05-21 at 17:48 +0000, Sven Geggus wrote:
> > Trond Myklebust <[email protected]> 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.
J. Bruce Fields schrieb am Donnerstag, den 28. Mai um 22:28 Uhr:
> 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
Hi,
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
On Thursday 28 May 2009 22:32:28 Sven Geggus wrote:
> J. Bruce Fields schrieb am Donnerstag, den 28. Mai um 22:28 Uhr:
> > 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