Steve Dickson wrote:
On 08/16/2011 04:01 AM, Shehjar Tikoo wrote:
Hi All
The following thread discusses the behaviour when the client does not support v4:
http://thread.gmane.org/gmane.linux.nfs/36928/
OTOH, when the server does not support v4, for eg. Gluster NFS server, where we support only v3, I believe v4 client will attempt to connect directly to port 2049 and receive connection failure errors on TCP. Does the current nfs client handle the situation where this results in a timeout for mount? We're hearing a report of a timeout occurring on the RHEL6 client because the server does not have v4 support. Could someone please shed some light on how this behaviour is handled at present? Thanks
Here is the current logic as to what will cause a fall back:
switch (errno) {
case EPROTONOSUPPORT:
/* A clear indication that the server or our
* client does not support NFS version 4. */
goto fall_back;
case ENOENT:
/* Legacy Linux servers don't export an NFS
* version 4 pseudoroot. */
goto fall_back;
case EPERM:
/* Linux servers prior to 2.6.25 may return
* EPERM when NFS version 4 is not supported. */
goto fall_back;
default:
return result;
}
fall_back:
return nfs_try_mount_v3v2(mi);
So in the case of the Gluster server, you are dropping into the
default case which is causing the time out.
In the above patch set, Mi patches the mount code
to fall back on EINVAL which is the current return value from
the kernel, when v4 is not configured. I'm not totally
against doing something like this, but this is very touchy
code since it could have negative effects on other legacy
servers.
So I'm thinking Mi's kernel patch that cause the kernel
to return EPROTONOSUPPORT, which is the correct return
value, is probably the better way to go...
Thanks Steve. My understanding is that Mi's patch is to handle the case
where the client does not support v4. Do you think the same patch will also
handle a server that does not support v4 and hence prevents a client from
connecting to 2049?
Thanks
-Shehjar
With that said, to get this type of functionality into
already released distros, maybe the mount patch should be
looked into since it much easier to back port and people
are more will to take nfs-utils updates than kernel updates...
So, if by chance, a well place bz is opened against an
already released distro, someone would have to make that
call... ;-)
steved.
--
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
