[callbacks] server not responding...

Trond Myklebust trond.myklebust at fys.uio.no
Wed Jul 11 10:04:01 EDT 2007


On Wed, 2007-07-11 at 14:19 +0100, Daniel J Blueman wrote:
> On 11/07/07, Trond Myklebust <trond.myklebust at fys.uio.no> wrote:
> > On Wed, 2007-07-11 at 13:54 +0100, Daniel J Blueman wrote:
> > > Yes, however this is actually a useful message that an administrator
> > > may want - perhaps it could even be at KERN_DEBUG level, but it shows
> > > a really useful symptom; better give the option to filter out.
> >
> > It sort of tells you whether or not the server is able to hand out
> > delegations to the client, but you are probably better off looking for
> > DELEGRETURN calls in /proc/self/mountstats on the client itself.
> >
> > > What were your thoughts on the the s/server/client/ question I had?
> >
> > In this case the server is in fact acting as a client to the client's
> > callback server.
> 
> This is what I understood, however in the context of 'NFS clients' and
> 'NFS servers', it would seem clearer from:
> 
> nfs4_cb: server 127.0.1.1 not responding, timed out
> 
> being changed to:
> 
> nfs4_cb: NFS client at 127.0.1.1 not responding, timed out
> 
> or:
> 
> nfs4_cb: callback service at 127.0.1.1 not responding, timed out
> 
> > The language describing it in RFC3530 gets quite
> > confusing too...
> 
> The people who will ultimately see and try to understand this message
> won't know the context for the callback reverse client-server model;
> perhaps it's a better recipe to err on the side of clarity?

No. We should simply suppress the message. If we want to inform
sysadmins that the server is unable to call the client back then that
should be done by entirely other means.

Trond



More information about the NFSv4 mailing list