From: Peter Staubach <staubach@redhat.com>
To: Steve Dickson <SteveD@redhat.com>
Cc: nfs@lists.sourceforge.net
Subject: Re: [PATCH nfs-utils 2/3] Correctly probe mount v2
Date: Mon, 05 Nov 2007 13:01:05 -0500 [thread overview]
Message-ID: <472F5A61.7090009@redhat.com> (raw)
In-Reply-To: <472EF773.5020200@RedHat.com>
Steve Dickson wrote:
> Neil Brown wrote:
>
>> diff --git a/utils/mount/network.c b/utils/mount/network.c
>> index 2b09457..38d0135 100644
>> --- a/utils/mount/network.c
>> +++ b/utils/mount/network.c
>> @@ -494,7 +494,7 @@ int probe_bothports(clnt_addr_t *mnt_server, clnt_addr_t *nfs_server)
>> for (; *probe_vers; probe_vers++) {
>> nfs_pmap->pm_vers = mntvers_to_nfs(*probe_vers);
>> if ((res = probe_nfsport(nfs_server) != 0)) {
>> - mnt_pmap->pm_vers = nfsvers_to_mnt(nfs_pmap->pm_vers);
>> + mnt_pmap->pm_vers = *probe_vers;
>> if ((res = probe_mntport(mnt_server)) != 0)
>> return 1;
>> memcpy(mnt_pmap, &save_mnt, sizeof(*mnt_pmap));
>>
>
> This patch does indeed fix mounts in the case where servers only support
> version 2 of the mount protocol. Meaning "mount server:/export /mnt/v2"
> now work when mountd only registers version 2 of the mnt protocol.
>
> But I happen to also notice that when setting the nfsvers
> "mount -o vers=2 server:/export /mnt/v2"
>
> the mount fails, because the mount command assumes version 1 (of the mnt
> protocol) should be used and never tries any other versions. A similar
> assumption is made on the umount side as well.
>
> So I guess the question is, what correlation (if any) is there between
> the mount version and nfs version that is used? Do nfsvers=2 mounts
> have to use version 1 of the mnt protocol? What is the problem if
> v3 mounts use version 2 of the mnt protocol?
>
>
MOUNT Version 2 is the same as MOUNT Version 1 plus the addition
of the Posix style PATHCONF operation. Thus, NFS Version 2 can
use either MOUNT Version 1 or MOUNT Version 2 to get the original
file handle.
MOUNT Version 3 was designed to be used with NFS Version 3. It
should not be used with earlier versions of the NFS protocols nor
should NFS Version 3 depend upon the file handles returned from
MOUNT Version 1 or MOUNT Version 2.
Most NFS server implementations _happen_ to use the same file
handles for NFS Version 2 and NFS Version 3, for ease of
implementation, but this is not a safe assumption to make on
behalf of a client.
Thanx...
ps
> My answers would be None, No and None to those questions, but maybe
> I'm missing something...
>
> Below is an RFC patch that removes these assumption:
>
> diff --git a/utils/mount/network.c b/utils/mount/network.c
> index 38d0135..c929986 100644
> --- a/utils/mount/network.c
> +++ b/utils/mount/network.c
> @@ -481,8 +481,12 @@ int probe_bothports(clnt_addr_t *mnt_server,
> clnt_addr_t *nfs_server)
>
> if (mnt_pmap->pm_vers && !nfs_pmap->pm_vers)
> nfs_pmap->pm_vers = mntvers_to_nfs(mnt_pmap->pm_vers);
> - else if (nfs_pmap->pm_vers && !mnt_pmap->pm_vers)
> - mnt_pmap->pm_vers = nfsvers_to_mnt(nfs_pmap->pm_vers);
> + else if (nfs_pmap->pm_vers && !mnt_pmap->pm_vers) {
> + /* Does it matter which mount version is used
> + * when the nfs version is set ?
> + */
> + mnt_pmap->pm_vers = 0;
> + }
> if (nfs_pmap->pm_vers)
> goto version_fixed;
>
> diff --git a/utils/mount/nfsumount.c b/utils/mount/nfsumount.c
> index 285273b..4209514 100644
> --- a/utils/mount/nfsumount.c
> +++ b/utils/mount/nfsumount.c
> @@ -195,12 +195,6 @@ static int do_nfs_umount23(const char *spec, char
> *opts)
> pmap->pm_prog = atoi(p+10);
> if (opts && (p = strstr(opts, "mountport=")) && isdigit(*(p+10)))
> pmap->pm_port = atoi(p+10);
> - if (opts && hasmntopt(&mnt, "v2"))
> - pmap->pm_vers = nfsvers_to_mnt(2);
> - if (opts && hasmntopt(&mnt, "v3"))
> - pmap->pm_vers = nfsvers_to_mnt(3);
> - if (opts && (p = strstr(opts, "vers=")) && isdigit(*(p+5)))
> - pmap->pm_vers = nfsvers_to_mnt(atoi(p+5));
> if (opts && (p = strstr(opts, "mountvers=")) && isdigit(*(p+10)))
> pmap->pm_vers = atoi(p+10);
> if (opts && (hasmntopt(&mnt, "udp") || hasmntopt(&mnt, "proto=udp")))
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> NFS maillist - NFS@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next prev parent reply other threads:[~2007-11-05 18:02 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-01 5:26 [PATCH nfs-utils] probe_port should not try other versions in a version was explicitly given Neil Brown
2007-11-01 5:26 ` [PATCH nfs-utils 1/3] " Neil Brown
2007-11-01 5:26 ` [PATCH nfs-utils 2/3] Correctly probe mount v2 Neil Brown
2007-11-01 5:26 ` [PATCH nfs-utils 3/3] Fix bug in auto-exporting subordinate mounts Neil Brown
2007-11-05 9:54 ` Steve Dickson
2007-11-05 10:58 ` [PATCH nfs-utils 2/3] Correctly probe mount v2 Steve Dickson
2007-11-05 18:01 ` Peter Staubach [this message]
2007-11-01 16:29 ` [PATCH nfs-utils 1/3] probe_port should not try other versions in a version was explicitly given Chuck Lever
2007-11-02 2:02 ` Neil Brown
2007-11-02 17:01 ` Chuck Lever
2007-11-05 9:55 ` Steve Dickson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=472F5A61.7090009@redhat.com \
--to=staubach@redhat.com \
--cc=SteveD@redhat.com \
--cc=nfs@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.