Fwd: Re: [2.6] nfs_rename: target $file busy, d_count=2

Fwd: Re: [2.6] nfs_rename: target $file busy, d_count=2

[Mike Fedyk]

On Thu, Jan 15, 2004 at 04:54:57PM -0800, Mike Fedyk wrote:
> On Thu, Jan 15, 2004 at 04:03:46PM -0800, Mike Fedyk wrote:
> > Both client and server are running the same 2.6.1-bk2 kernel with TCP-NFS.
> > SMP, Highmem, & preempt.
> 
> I have four clients that are all having this problem also, three 2.6, and
> one 2.4 client.
> 
> Using TCP-NFS they all have stale nfs handles even after a reboot (only
> rebooted one to try with 2.4.23), but changed one to UDP-NFS, and it didn't
> have the stale handles.
> 
> Will do more testing with UDP-NFS.

No, TCP and UDP NFS both get stale file handles. :(

Can anyone reproduce?


----- End forwarded message -----

Re: Fwd: Re: [2.6] nfs_rename: target $file busy, d_count=2

[Patrick Mau]

On Thu, Jan 15, 2004 at 09:06:42PM -0800, Mike Fedyk wrote:
> On Thu, Jan 15, 2004 at 04:54:57PM -0800, Mike Fedyk wrote:
> > On Thu, Jan 15, 2004 at 04:03:46PM -0800, Mike Fedyk wrote:
> > > Both client and server are running the same 2.6.1-bk2 kernel with TCP-NFS.
> > > SMP, Highmem, & preempt.
> > 
> > I have four clients that are all having this problem also, three 2.6, and
> > one 2.4 client.
> > 
> > Using TCP-NFS they all have stale nfs handles even after a reboot (only
> > rebooted one to try with 2.4.23), but changed one to UDP-NFS, and it didn't
> > have the stale handles.
> > 
> > Will do more testing with UDP-NFS.
> 
> No, TCP and UDP NFS both get stale file handles. :(
> 
> Can anyone reproduce?

Hi,

I was able to reproduce stale handles a long time ago.
A workable solution for me was to export using 'no_subtree_check'
on the server. Like this:

/data \
  tony.local.net(rw,sync,no_root_squash,no_subtree_check) \

Could you please try and reply to my address if t works ?

Thanks,
Patrick

Re: [2.6] nfs_rename: target $file busy, d_count=2

[Mike Fedyk]

On Fri, Jan 16, 2004 at 02:03:36PM +0100, Patrick Mau wrote:
> On Thu, Jan 15, 2004 at 09:06:42PM -0800, Mike Fedyk wrote:
> > Can anyone reproduce?
> 
> Hi,
> 
> I was able to reproduce stale handles a long time ago.
> A workable solution for me was to export using 'no_subtree_check'
> on the server. Like this:
> 
> /data \
>   tony.local.net(rw,sync,no_root_squash,no_subtree_check) \
> 
> Could you please try and reply to my address if t works ?

I'll have to give it a try next time I get a chance to reboot this server.

I only had a few nfs clients doing light load, (kde home directories, and
such) and was able to reproduce stale nfs file handles just by running "find
> /dev/null" on the nfs share.

Have you tried the -mm tree recently?  2.6.1-mm4 even has some new nfsd
patches in there (maybe you should wait until -mm5 though, there are a few
build problems and such), as well as over 20 nfs client patches.  Haven't
checked what they all do, but some of them are RPC_GSS support mixed in with
the bug fixes.

Mike

Stale Filehandles was: [2.6] nfs_rename: target $file busy, d_count=2

[Mike Fedyk]

On Fri, Jan 16, 2004 at 10:40:31AM -0800, Mike Fedyk wrote:
> I only had a few nfs clients doing light load, (kde home directories, and
> such) and was able to reproduce stale nfs file handles just by running "find
> > /dev/null" on the nfs share.
> 
> Have you tried the -mm tree recently?  2.6.1-mm4 even has some new nfsd
> patches in there (maybe you should wait until -mm5 though, there are a few

Stale filehandles is the main problem right now, and I don't see how
nfs_raname would be related (just that it was there while I was having
trouble with the stale file handles...)

http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1/2.6.1-mm4/broken-out/nfsd-01-stale-filehandles-fixes.patch

This one looks particularly interesting...

Re: Stale Filehandles was: [2.6] nfs_rename: target $file busy, d_count=2

[Mike Fedyk]

On Fri, Jan 16, 2004 at 10:55:04AM -0800, Mike Fedyk wrote:
> On Fri, Jan 16, 2004 at 10:40:31AM -0800, Mike Fedyk wrote:
> > I only had a few nfs clients doing light load, (kde home directories, and
> > such) and was able to reproduce stale nfs file handles just by running "find
> > > /dev/null" on the nfs share.
> > 
> > Have you tried the -mm tree recently?  2.6.1-mm4 even has some new nfsd
> > patches in there (maybe you should wait until -mm5 though, there are a few
> 
> Stale filehandles is the main problem right now, and I don't see how
> nfs_raname would be related (just that it was there while I was having
> trouble with the stale file handles...)
> 
> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1/2.6.1-mm4/broken-out/nfsd-01-stale-filehandles-fixes.patch
> 
> This one looks particularly interesting...
> 

Most of the nfs client patches are for NFS4 or RPCSEC_GSS.  Except for:

http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1/2.6.1-mm4/broken-out/

nfs-26-sock_disconnect.patch
nfs-31-attr.patch
nfs-client-deadlock-fix.patch
nfs-fix-bogus-setattr-calls.patch
nfs-open-intent-fix.patch
nfs-optimise-COMMIT-calls.patch
nfs-readonly-mounts-fix.patch
nfs-rpc-debug-oops-fix.patch

These might be interesting to test, but so far I haven't had troubles with
the stock Linus 2.6 nfs3 client.

Mike

[SOLVED] Stale Filehandles was: [2.6] nfs_rename: target $file busy, d_count=2

[Mike Fedyk]

On Sat, Jan 17, 2004 at 10:47:16AM -0800, Mike Fedyk wrote:
> On Fri, Jan 16, 2004 at 10:55:04AM -0800, Mike Fedyk wrote:
> > On Fri, Jan 16, 2004 at 10:40:31AM -0800, Mike Fedyk wrote:
> > > I only had a few nfs clients doing light load, (kde home directories, and
> > > such) and was able to reproduce stale nfs file handles just by running "find
> > > > /dev/null" on the nfs share.
> > > 
> > > Have you tried the -mm tree recently?  2.6.1-mm4 even has some new nfsd
> > > patches in there (maybe you should wait until -mm5 though, there are a few
> > 
> > Stale filehandles is the main problem right now, and I don't see how
> > nfs_raname would be related (just that it was there while I was having
> > trouble with the stale file handles...)
> > 
> > http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1/2.6.1-mm4/broken-out/nfsd-01-stale-filehandles-fixes.patch
> > 
> > This one looks particularly interesting...
> > 
> 
> I'm running 2.6.1-bk2-nfs-stale-file-handles on my nfsd server now, and so
> far I haven't seen any stale filehandles.
> 
> Can you guys patch stock 2.6.1 with the above and test also so we can get
> more breadth in the testing results?
> 

Well, it's been running since friday with the same load that killed it in
less than a day, so I'm happy.

And BTW, the code has been merged by Linus and is in 2.6.1-bk6.

Mike

Fwd: Re: [2.6] nfs_rename: target $file busy, d_count=2

[Mike Fedyk]

On Thu, Jan 15, 2004 at 04:54:57PM -0800, Mike Fedyk wrote:
> On Thu, Jan 15, 2004 at 04:03:46PM -0800, Mike Fedyk wrote:
> > Both client and server are running the same 2.6.1-bk2 kernel with TCP-NFS.
> > SMP, Highmem, & preempt.
> 
> I have four clients that are all having this problem also, three 2.6, and
> one 2.4 client.
> 
> Using TCP-NFS they all have stale nfs handles even after a reboot (only
> rebooted one to try with 2.4.23), but changed one to UDP-NFS, and it didn't
> have the stale handles.
> 
> Will do more testing with UDP-NFS.

No, TCP and UDP NFS both get stale file handles. :(

Can anyone reproduce?


----- End forwarded message -----

Fwd: Re: [2.6] nfs_rename: target $file busy, d_count=2

[Mike Fedyk]

----- Forwarded message from Mike Fedyk <mfedyk@matchmail.com> -----

Date: Thu, 15 Jan 2004 16:54:57 -0800
From: Mike Fedyk <mfedyk@matchmail.com>
To: linux-kernel@vger.kernel.org
Subject: Re: [2.6] nfs_rename: target $file busy, d_count=2

On Thu, Jan 15, 2004 at 04:03:46PM -0800, Mike Fedyk wrote:
> Both client and server are running the same 2.6.1-bk2 kernel with TCP-NFS.
> SMP, Highmem, & preempt.

I have four clients that are all having this problem also, three 2.6, and
one 2.4 client.

Using TCP-NFS they all have stale nfs handles even after a reboot (only
rebooted one to try with 2.4.23), but changed one to UDP-NFS, and it didn't
have the stale handles.

Will do more testing with UDP-NFS.

Mike


----- End forwarded message -----