Re: v4recovery client id lockup

["J. Bruce Fields" <bfields@fieldses.org>]

On Fri, Feb 24, 2012 at 01:08:54PM -0800, Louie wrote:
> Thanks for the help, I think I've tracked this down in case anybody
> else ever runs into same issue.
> 
> We have multiple clients connecting via SSH tunnels, so all NFS
> traffic is routed through localhost (127.0.0.1) on these open ports.
> 
> The problem appears to be the NFS server only partially recognizing
> diff. between these clients through local tunnels. Upon each
> alternating connection, the /var/lib/nfs/rpc_pipefs/nfsd4_cb/clntID
> directory is replaced with a new one (shows the same IP address of
> 127.0.0.1, but a new port). The v4recovery client's hash directory is
> removed/replaced with the exact same hash. Obviously, when multiple
> clients are hitting the box at the same time, this causes a lockup.
> 
> I'm guessing there is no solution and our setup just isn't supported.
> I'm leaning towards ditching the SSH tunnels and going with
> unencrypted traffic for now, as it's not strictly necessary. But if
> anybody has a tip on how to fix, would love to hear.

That's very strange: those directory names are created as a hash of the
clientid that the client sends in setclientid.

Hm, but the linux client generates those using its idea of its IP and
the server's IP, and maybe those both end up being the same for all your
clients.  Giving each client mount command a distinct cilentaddr= option
might help?

And I also wonder if the server's doing the right thing here--could be
it should be returning a clientid_inuse error to most of the clients
instead of whatever it's currently doing (probably assuming it has one
client that's rebooting continually)--but it may be hard for it to tell
the difference.

--b.