On Apr 28, 2008, at 2:24 PM, Frank A. Kingswood wrote:
Chuck Lever wrote:
The NFS client code (nfs-utils-1.1.2) tests for
if (kernel_version > MAKE_VERSION(2, 6, 22))
yet the kernel patch for NFS did not go un until 2.6.25-rc2
So the test should at least be > MAKE_VERSION(2, 6, 24).
The original NFS text-based mount support was added in 2.6.23.
OK.
New features will be added only to the text-based mount interface,
however, so eventually everyone will need to use the text-based
mount interface on new kernels.
That sounds like a good idea.
Because we have little documented history and only a handful of use
cases and unit tests for the mount command, it's important for
everyone to test the new API and report problems here so we can
address them. NFS mount is complex and has many subtle and hidden
historical behaviors.
My system fails with 2.6.23 and 2.6.25 kernels. As I described in my
original mail, I only have TCP access to the server, and only
through an ssh tunnel.
Would you like me to try and produce some debug traces, or do you
think you can find the problem with the information you have
already? I've seen quite a few reports of this now.
Thanks for the offer. I tested against a server configuration that
dropped UDP packets, but I never tested through an ssh tunnel.
Network traces might be a little hard with a tunnel, but give it a
shot. The best information comes from a full-packet raw trace. Use
the "-s0" option on tcpdump.
You can also trace NFS mount processing with:
# sysctl -w sunrpc.nfs_debug = 128
Or trace all RPC activity (including rpcbind and RPC network transport
errors) with:
# sysctl -w sunrpc.rpc_debug = 32767
You can set both of these at the same time. Trace output will appear
in /var/log/messages. To disable tracing when you're done, set these
sysctls to zero.
You can post these to me privately.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
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
