On Thu, 18 Jun 2015 21:37:02 -0400 Jeff Layton <jlayton@xxxxxxxxxxxxxxx> wrote: > > Note, the box has been rebooted since I posted my last trace. > > > > Ahh pity. The port has probably changed...if you trace it again maybe > try to figure out what it's talking to before rebooting the server? I could probably re-enable the trace again. Would it be best if I put back the commits and run it with the buggy kernel. I could then run these commands after the bug happens and/or before the port goes away. > Oh! I was thinking that you were seeing this extra port on the > _client_, but now rereading your original mail I see that it's > appearing up on the NFS server. Is that correct? Correct, the bug is on the NFS server, not the client. The client is already up and running, and had the filesystem mounted when the server rebooted. I take it that this happened when the client tried to reconnect. Just let me know what you would like to do. As this is my main production server of my local network, I would only be able to do this a few times. Let me know all the commands and tracing you would like to have. I'll try it tomorrow (going to bed now). -- Steve > > So, assuming that this is NFSv4.0, then this port is probably bound > when the server is establishing the callback channel to the client. So > we may need to look at how those xprts are being created and whether > there are differences from a standard client xprt. > -- 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
