[2.6] nfs_rename: target $file busy, d_count=2
Quoted 5 lines · Mike Fedyk
1.
nfs_rename: target $file busy, d_count=2
2. RPC request reserved 0 but used 40Hi, I'm getting [1] in kernel log on the nfs client, and [2] on the nfs server. After that I get nfs stale file handles.
I started to get "RPC request reserved 0 but used X" where X ranged from 24 to 32900, when I switched from NFS over UDP to NFS over TCP. Both servers and clients are on vanilla 2.6.1, one of the servers exibiting this does only readonly exports. There are no apparent effects associated with that message, however the comment in svc_sock_release() in net/sunrpc/svcsock.c says that it's an indication of a bug. I'll try to run it with debugging enabled to see on which code path it happens.
I don't see your nfs_rename problem on the clients. Nor do they get stale NFS handles: there used to be some until I added no_subtree_check export option.
Quoted 2 lines
Both client and server are running the same 2.6.1-bk2 kernel with TCP-NFS. SMP, Highmem, & preempt.
In my case UP, no highmem, no preempt.
Roman.
På fr , 16/01/2004 klokka 07:32, skreiv Roman Kagan:
Quoted 3 lines
I don't see your
nfs_renameproblem on the clients. Nor do they get stale NFS handles: there used to be some until I addedno_subtree_checkexport option.
Sure. subtree checking will break renames if you rename from one directory to another. This is not a new 2.6 feature. It occurs on 2.4 servers too...
It is because a server with subtree checking enabled will encode the parent directory inside the filehandle. When you rename so that the parent directory changes, the old filehandle becomes stale.
Cheers,
Trond