Chuck Lever [Thu, 18 Feb 2010 11:41:11 +0000 (06:41 -0500)]
mount: Set protocol family properly for "udp" and "tcp"
In nfs_nfs_proto_family(), *family is never set if the legacy
"udp" or "tcp" mount options are specified. The result is an error
message at umount time, for example:
umount.nfs: DNS resolution failed for
2001:5c0:1101:2f00:250:8dff:fe95:5c61: ai_family not supported
even if mount was built with IPv6 support.
The man page says that "udp" is a synonym for "proto=udp", and
likewise for "tcp". Thus, we don't look at config_default_family
here, but always use AF_INET explicitly, to be consistent with the
meaning of proto=.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Reviewed-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve Dickson <steved@redhat.com>
Steve Dickson [Wed, 17 Feb 2010 19:38:19 +0000 (14:38 -0500)]
nfsd: Disble NFS 4.1 functionality by default
Due to the fact the current kernel code do not completely
conform to the NFS 4.1 RFC, this patch disable the 4.1 support
on the server.
To control this 41 functionality, the NFS41_SUPPORTED
configuration variable now exist that will allow us to
re enable the functionality without any code changes.
Jeff Layton [Fri, 12 Feb 2010 19:33:34 +0000 (14:33 -0500)]
mount.nfs: return error if proto= option specified IPv6 when IPv6 isn't supported
Right now, there's nothing that expressly forbids someone from
specifying proto=tcp6 for instance, even when nfs-utils it built without
IPv6 support. This may not work well if (for instance) they are using
NFSv3, since statd won't support IPv6. Explicitly return an error if
someone specifies an IPv6 proto= or mountproto= option and IPv6 isn't
supported.
Signed-off-by: Jeff Layton <jlayton@redhat.com> Reviewed-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Steve Dickson <steved@redhat.com>
Chuck Lever [Fri, 12 Feb 2010 19:26:46 +0000 (14:26 -0500)]
statd: Remove SIMU_CRASH warning
SM_SIMU_CRASH isn't used, so this warning is never seen today.
However, if we ever wanted to use SM_SIMU_CRASH, this warning
is unnecessarily alarming, and serves no real purpose.
At some point in the near future I'd like us to consider using
SM_SIMU_CRASH, so let's get rid of this message now.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Steve Dickson <steved@redhat.com>
Jeff Layton [Fri, 12 Feb 2010 19:23:16 +0000 (14:23 -0500)]
This is the second iteration of this patch. The only difference here
is that this one has default_value call nfs_nfs_proto_family regardless
of whether IPV6_SUPPORTED is set.
When IPv6 is enabled, the Proto= config file option is treated as a
netid, and the address family for lookups is selected based on that
setting. The Defaultproto= option however still only affects the
protocol setting for the sockets (IPPROTO_*) and not the address family.
This patch makes it so that if someone sets the "Defaultproto=" option
in the nfsmount.conf, it's used to determine the default address family
for lookups as well as the protocol type.
This gives users a way to force a particular address family to be used
universally for mounts and brings the behavior of the Defaultproto=
option in line with the Proto= option.
Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve Dickson <steved@redhat.com>
Chuck Lever [Fri, 12 Feb 2010 18:38:59 +0000 (13:38 -0500)]
text-based mount: Support protocol family negotiation
Jeff Layton pointed out that the current negotiation logic in
stropts.c simply doesn't handle the case where a server may have an
IPv6 address and an IPv4 address, but only NFS/IPv4 is supported.
This is typical of all currently deployed Linux servers.
Add support for trying all addresses returned from DNS when
"proto=" is not specified on the command line.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Steve Dickson <steved@redhat.com>
Chuck Lever [Fri, 12 Feb 2010 18:36:17 +0000 (13:36 -0500)]
text-based mount: Set addr= option in nfs_try_mount_foo()
When retrying a mount request with a different server address, the
addr= option may change each time through the fg/bg loop.
Instead of setting the addr= option in nfs_validate_options(), set it
in nfs_try_mount_v2v3() and nfs_try_mount_v4(). This is much the
same thing we did recently with the version-specific mount options
which might change each time through the fg/bg retry loop.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Steve Dickson <steved@redhat.com>
Chuck Lever [Fri, 12 Feb 2010 18:10:03 +0000 (13:10 -0500)]
text-based mount: Replace nfs_lookup() with getaddrinfo(3)
Originally I thought it would be best to share the DNS query code
between the legacy mount code and the new text-based code, hence
the introduction of nfs_lookup(). However, it now appears we want
the text-based code to do a little more than take the first address
returned by the query.
So, let's invoke getaddrinfo(3) directly in stropts.c, and save
the returned addrinfo struct until the end of processing.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Steve Dickson <steved@redhat.com>
Chuck Lever [Fri, 12 Feb 2010 18:04:14 +0000 (13:04 -0500)]
text-based mount: Retry when server can't be reached
We want new default behavior from mount.nfs when the server refuses a
connection. Since connection refusal can be spurious (for example,
if the server is rebooting), mount.nfs should retry.
NFS shares that are automatically mounted by /etc/fstab at boot
time may be problematic. The new behavior can be disabled by
specifying the "retry=0" mount option, or these mounts can be changed
to background mounts by specifying the "bg" option.
A kernel code change is still required for the mount(2) system call to
return ECONNREFUSED for NFSv4 mounts (see 2.6.33). For v2/v3, the
version and transport negotiation logic in mount.nfs should drive a
retry if the server's rpcbind can't be reached.
Note that if a v2/v3 mount request encounters an unregistered NFS
service, it will still fail immediately. That wouldn't be too hard
to change as well, but there are many more corner cases there where
failing immediately is appropriate.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Steve Dickson <steved@redhat.com>
J. Bruce Fields [Thu, 4 Feb 2010 22:03:53 +0000 (17:03 -0500)]
nfsd: fix version-setting regression on old kernels
/proc/fs/nfsd/versions was extended to allow turning on/off minor
versions by echoing "+4.1" or "-4.1" to /proc/fs/nsfd/versions.
Unfortunately, pre-2.6.30 kernels just stop parsing at first non-digit,
so "-4.1" is interpreted as "-4". If new nfs-utils (on old kernel)
writes "+2", "+3", "+4", then "-4.1", result therefore is to turn off
4.1.
Given that historical behavior, it may have been a mistake to extend the
interface the way we did; but at this point we're probably stuck with
it. So, just reverse the order we write versions in.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Steve Dickson <steved@redhat.com>