On Tue, 21 Aug 2012 12:52:16 +0000 (UTC) Sven Geggus <lists@xxxxxxxxxxxxxxxxxxxxx> wrote: > Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > > It's often the case that this indicates a problem communicating over > > the callback channel. For instance, the server is trying to recall a > > delegation but the client isn't responding, so the server has to wait > > until the recall attempt times out before proceeding. > > Hm I'm not shure if I understand this correctly. > > I am talking about exactly 3 machines (and one single user for now) here: > clientA, clientB and the NFS-server. > > "user" is logged in on clientA any now opens a shell to ssh to clientB. > Right, so you probably opened ~/Xauthority on clientA and got a delegation. Then you ssh'ed to clientB and opened the file there. At that point, the server has to recall the delegation. Usually that's pretty quick, but if the server can't talk to clientA on the callback port then it has to wait and eventually time out before it can allow the open on clientB to proceed. > The NFS-server is providing the home for the user on both machines. > > The ssh is now getting delayed for up to 1 minute because the NFS server > does not allow for the .Xauthority file to be deleted immediately. > > It is probably worth to mention, that I'm currently experimenting with > btrfs on the server. Is there a chance that this bug will disapper when I > change the underlaying filesystem of the server to ext4? > > Sven > You asked for hints on how to debug it, and I gave one. The server will often return NFS4ERR_DELAY when it's waiting for a delegation recall to complete. I'd make sure that that's all working as expected. -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
