From: Steve Dickson <SteveD@redhat.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: [PATCH] nfsmount.conf: New variables that explicitly set default
Date: Fri, 09 Oct 2009 19:16:40 -0400 [thread overview]
Message-ID: <4ACFC458.8060107@RedHat.com> (raw)
In-Reply-To: <6E43AB0D-AC26-411F-A8CF-146E02F8AADA@oracle.com>
First of all thank you for you comments so soon..
They are very much appreciated!
On 10/09/2009 04:29 PM, Chuck Lever wrote:
> On Oct 9, 2009, at 2:16 PM, Steve Dickson wrote:
>> This patch introduces two new mount configuration variables used
>> to set the default protocol version and network transport.
>>
>> Currently when the nfsvers or proto is set in the nfsmount.conf
>> file the mount will fail if the server does not support
>> the given version or transport. No negation with the server occurs.
>>
>> With default values, they define where the server negation should start.
>> So the 'default_nfsvers=' and default_proto=' will now define where the
>> server negation will start. Meaning just because they are set to a
>> certain value does not meant that will be the final value used in
>> mount.
>>
>> comments?
>
> I worry that this kind of thing will be difficult to support when we
> move version and transport negotiation into the kernel.
There was a lot of positive feed back on being able to control
things like defining the default version and transport from user
level configuration files. But I do understand your point, so maybe
its not a good idea to move negotiation down to the kernel. I think its
clear that is much easier to support and change these types of
negotiations from user level...
>> diff --git a/utils/mount/stropts.c b/utils/mount/stropts.c
>> index 069bdc1..b203414 100644
>> --- a/utils/mount/stropts.c
>> +++ b/utils/mount/stropts.c
>> @@ -92,6 +92,13 @@ struct nfsmount_info {
>> child; /* forked bg child? */
>> };
>>
>> +#ifdef MOUNT_CONFIG
>> +#include "conffile.h"
>> +int inline config_defaults(struct nfsmount_info *mi);
>> +#else
>> +int inline config_defaults(struct nfsmount_info *mi) {return 0;}
>> +#endif
>> +
>> /*
>> * Obtain a retry timeout value based on the value of the "retry="
>> option.
>> *
>> @@ -610,10 +617,22 @@ static int nfs_try_mount(struct nfsmount_info *mi)
>> case 2:
>> case 3:
>> result = nfs_try_mount_v3v2(mi);
>> + if (result)
>> + break;
>> +
>> + if (config_defaults(mi))
>> + result = nfs_try_mount_v3v2(mi);
>> break;
>> +
>> case 4:
>> result = nfs_try_mount_v4(mi);
>> + if (result)
>> + break;
>> +
>> + if (config_defaults(mi))
>> + result = nfs_try_mount_v3v2(mi);
>> break;
>> +
>> default:
>> errno = EIO;
>> }
>
> A better approach to all of this might be to use the config file to set
> mi->version. mi->version already controls which versions are tried
> here. Do away with the idea of adding mount options to get default
> version behavior.
>
> If mi->version is 0, we get full v4/v3/v2 negotiation. If mi->version
> is 3, we get just v2 and v3. Do we need any more flexibility than that?
Well at the point where the config file is being read, there is no
access to the struct nfsmount_info since it local to the mount/stropts.c
file. That could change but I kinda like the way its designed...
>
> All you have to do is this: in nfs_validate_options(), after we've
> looked at the user option string to see what version is specified,
> check: if mi->version is still 0, then look in the config file to see
> what kind of negotiation behavior is desired. Done.
This does not jive with how the config parsing code works. The code
appends to the current options (if they don't already exists), well
before nfs_validate_options() is called..
I'm not saying using the mi->version to start the negotiation is
bad idea, its just not available when the configuration file
is read..
>
> I'd say you should split the "default protocol" option into a separate
> patch, because something quite different will be needed there.
yeah, that was laziness on my part... But if figured the code was
not that complicated so I figured I could get away with it..
> But I'm still not clear on why someone wouldn't just say "proto=udp" or
> "proto=rdma" to avoid negotiating.
They can and that's the way it works today... What I'm introducing is a
negotiable variable that will allow mount to succeed when servers don't
support the client first offering.
steved.
next prev parent reply other threads:[~2009-10-09 23:17 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-09 18:16 [PATCH] nfsmount.conf: New variables that explicitly set default Steve Dickson
[not found] ` <4ACF7E0D.6060202-AfCzQyP5zfLQT0dZR+AlfA@public.gmane.org>
2009-10-09 20:29 ` Chuck Lever
2009-10-09 23:16 ` Steve Dickson [this message]
[not found] ` <4ACFC458.8060107-AfCzQyP5zfLQT0dZR+AlfA@public.gmane.org>
2009-10-10 0:38 ` Chuck Lever
2009-10-12 9:24 ` Steve Dickson
[not found] ` <4AD2F5B7.9040900-AfCzQyP5zfLQT0dZR+AlfA@public.gmane.org>
2009-10-12 15:16 ` Chuck Lever
2009-10-12 17:10 ` Steve Dickson
[not found] ` <4AD36309.1090202-AfCzQyP5zfLQT0dZR+AlfA@public.gmane.org>
2009-10-15 15:01 ` Chuck Lever
2009-10-19 12:38 ` Steve Dickson
[not found] ` <4ADC5DC8.90500-AfCzQyP5zfLQT0dZR+AlfA@public.gmane.org>
2009-10-21 17:37 ` Chuck Lever
2009-10-21 20:31 ` Steve Dickson
[not found] ` <4ADF6FA2.50801-AfCzQyP5zfLQT0dZR+AlfA@public.gmane.org>
2009-10-23 17:20 ` J. Bruce Fields
2009-10-23 17:26 ` Chuck Lever
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=4ACFC458.8060107@RedHat.com \
--to=steved@redhat.com \
--cc=chuck.lever@oracle.com \
--cc=linux-nfs@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox