[callbacks] server not responding...

[Daniel J Blueman]

On 11/07/07, Trond Myklebust <trond.myklebust at fys.uio.no> wrote:
> On Wed, 2007-07-11 at 13:30 +0100, Daniel J Blueman wrote:
> > On 11/07/07, Trond Myklebust <trond.myklebust at fys.uio.no> wrote:
> > > On Wed, 2007-07-11 at 10:07 +0100, Daniel J Blueman wrote:
> > > > On my multi-homed clients, I have only one interface up and loopback,
> > > > so could there not be logic at the client end to send the right
> > > > address that the server should use for callbacks, rather than
> > > > 127.0.1.1 being given?
> > >
> > > I've got a patch that hacks into the networking layer in order to do
> > > this, but it needs cleaning up: we should really set up a proper
> > > interface to allow the kernel to do this sort of thing. Both AFS and
> > > NFSv4 need it.
> >
> > Great. That said, the message "nfs4_cb: server 127.0.1.1 not
> > responding, timed out" is a little misleading, since it's actually
> > connecting to a service on the NFS client.
> >
> > Do you think it makes sense to tweak this while we're at it?
>
> I don't see why the server should be printing out any such messages at
> all. <looks>
> Ah... It would appear to be a casualty of the purge that Chuck made of
> the rpc_clnt->cl_chatty flag. There is definitely a use for that to turn
> off the "server not responding" message in cases such as this, where
> we're doing probes for whether an RPC service is up or not.

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.

What were your thoughts on the the s/server/client/ question I had?

Daniel
-- 
Daniel J Blueman