setclientid: string in use on NFS v4 share on Debian Etch & hosts file "solution"
J. Bruce Fields
bfields at fieldses.org
Fri Nov 9 14:55:30 EST 2007
On Wed, Nov 07, 2007 at 03:47:08PM -0800, Matt Weatherford wrote:
>
> Hi,
>
> Im not sure this is the right place to ask, but Im wondering if someone can
> illuminate what the following console messages means on my NFS v4 server....
>
>
> NFSD: setclientid: string in use by client(clientid 471c1b08/000003e9)
> NFSD: setclientid: string in use by client(clientid 471c1b08/00000410)
> nfs4_cb: server 10.11.12.221 not responding, timed out
> nfs4_cb: server 10.11.12.222 not responding, timed out
> NFSD: setclientid: string in use by client(clientid 471c1b08/0000043a)
> NFSD: setclientid: string in use by client(clientid 471c1b08/0000043c)
> NFSD: setclientid: string in use by client(clientid 471c1b08/00000447)
> NFSD: setclientid: string in use by client(clientid 471c1b08/0000044d)
> NFSD: setclientid: string in use by client(clientid 471c1b08/00000453)
> nfs4_cb: server 10.11.12.221 not responding, timed out
The "nfs4_cb: server not responding" mean the server is failing to open
a connection back to the client to use for callbacks, which means it
won't give out delegations. That's not a fatal error at all, it's just
a possible lost opportunity for a performance improvement.
The "string in use" errors could be a sign that clients might fail to
recover locks when the server reboots. But if the clients aren't
complaining, I wouldn't worry about it. There have been changes to
nfs-utils and the kernel to make those clientid collisions less likely,
but I don't recall whether they went in before or after 2.6.18.
The "string in use" message is no longer logged by the server by default
in recent kernels, and the "not responding" comment needs to be removed
sometime too; I wouldn't worry about them.
>
> (and yes, those IPs (10.11.12.221, 222) are good)
>
>
> I am on Debian Etch, on x86 hardware, using multiple NFS v4 clients with
> all the latest package updates.
>
> I have multiple other NFS clients which the server is not complaining about.
> I am sharing NFSv4 shares on both (2) NIC's.
>
>
> NFS v4 client:
>
> client42:~# uname -a
> Linux client42 2.6.18-5-686 #1 SMP Wed Oct 3 00:12:50 UTC 2007 i686 GNU/Linux
> client42:~# apt-show-versions | grep nfs
> libnfsidmap2/etch uptodate 0.18-0
> nfs-common/etch uptodate 1:1.0.10-6+etch.1
> client42:~#
>
>
> mount
> client42:~# mount
> ...omittted non v4 shares...
> yadda:/etch-llocal on /net/LLocal4 type nfs4
> (rw,hard,intr,rsize=32768,wsize=32768,addr=192.168.105.123)
> client42:~>
>
>
>
>
> NFS v4 server:
>
> yadda:~# apt-show-versions | grep -i nfs
> nfs-common/etch uptodate 1:1.0.10-6+etch.1
> nfs-kernel-server/etch uptodate 1:1.0.10-6+etch.1
> libnfsidmap2/etch uptodate 0.18-0
> yadda:~#
>
>
> Im not sure that this is the answer, but somewhere I saw a thread that I may
> need to name the host like this in my hosts table on my nfsv4 client:
>
> 127.0.0.1 localhost
> 127.0.1.1 client42
>
> If this is the solution (is it?)
I suspect that'd be a step backwards.
--b.
More information about the NFSv4
mailing list