Re: [Patch 0/9] NFS Mount Configuration File

[Steve Dickson <SteveD@redhat.com>]

Sorry for the delayed response... 

Chuck Lever wrote:
> Hi Steve-
> 
> On Mar 9, 2009, at Mar 9, 2009, 4:44 PM, Steve Dickson wrote:
>> Hello,
>>
>> The following patch set introduces a configuration file where
>> mount options can be define. The options in the file can be
>> applied globally or per server or per mount point.
>>
>> The patch set reuses the configuration parsing code that
>> idmapd uses. I did added a couple enhancements like ignoring
>> blanks in certain definitions as well as at the beginning of
>> assignment statements.
>>
>> There are man pages include in the patch set but in a
>> nut shell, the configuration file has three basic types
>> of sections. A global section, server section and mount point
>> section. There can only be one global section and multiple
>> server and mount point sections.
>>
>> The mount command prioritize these sections in the following
>> way:
>>     * Options on the command line are always used.
>>
>>     * Options defined in the mount point section are used
>>       as long a the options are not in the command line options.
>>
>>     * Options defined in the server section are used as long as
>>       they are not defined on the command line or in the mount point
>>       section.
>>
>>     * Options defined in the global section are used as long as the
>>       options are not on the command line or in the mount point section
>>       or in the server section.
> 
> This can become challenging to troubleshoot if there are these
> semi-hidden options (cf. selinux).
Why? 'mount -v' clearly shows what options are being used and then 
of course 'cat /proc/mounts' will show all the mount options.

> 
> I don't get why the per-mount section is even needed -- currently, the
> mount options in /etc/fstab are used automatically if no options are
> specified on the command line.
Sure... this is option redundant with /etc/fstab but why not allow people
configure all the NFS mounts in one spot? Why make them edit different files?
Plus it was just really easy to do... 
 
> 
> Is there a specific use case you have in mind for the per-mount
> section?  
Not really... I figure would handy allow different options on
different file system to the same server...

> You just want a user to say "-o noac" and she will get all the
> remaining options in the per-mount section too?  
Yes.. the per-mount section will be added on to the command line options.

> I guess that means you also need to know when to specify the opposite to 
> turn off the options listed in this section (like using "-o ac" if noac 
> is contained in this section).  So again, that doesn't seem like especially 
> helpful behaviour in some cases.
Not sure I understand your point... but regardless setting 'ac=true' will 
cause the '-o ac' option to be added and 'ac=false' will cause the
'-o noac' option to be added... 
 
> 
> This scheme doesn't allow conditional options: "always use retrans=10 if
> proto=udp was specified, but retrans=2 if proto=tcp was specified."
True.. conditional options are not supported... until there is a demand
for them... 

> 
>> This is the first step toward moving the default NFS version from 3 to 4
>> on the client.
> 
> I would think that the _only_ step is to implement the version fallback
> logic; ie. if the server doesn't support NFSv4, then use NFSv3, then
> NFSv2.  Why can't an admin simply specify a fixed NFS version
> (nfsvers=3) if there is a problem with NFSv4?  
They can... Nfsvers=3. When that is set, there will be no negotiation  


> It seems to me that if the admin hasn't specified nfsvers=, then she does 
> not care which NFS version is used.
True. And then the highest version the server supports
will be negotiated. Having a Max/Min version will allow a the
client to control that negotiation... Say the want v4 but not
v4.1 ? Or may they only v41? 

> 
>> Having a configuration file which allows users to define
>> the maximum and minimum NFS versions that should be negotiated is the
>> right thing to do... IMHO.. Even though this patch does not does not
>> do that, it does lay the ground work for that type of functionality
Well I think most admins do want complete control over which NFS
version will or will not be used... esp when it comes to v4 and v4.1

thanks!

steved.