The text-based mount interface doesn't support -s (--sloppy)

The text-based mount interface doesn't support -s (--sloppy)

[Steinar H. Gunderson]

Hi,

Another user-reported regression. -s used to work, but since 1.1.2 it does
not, probably due to the text-based interface somehow:

  fugl:~> sudo mount.nfs 10.0.0.10:/store /store -s -o rw,asdfasdf   
  mount.nfs: an incorrect mount option was specified

/* Steinar */
-- 
Homepage: http://www.sesse.net/

Re: The text-based mount interface doesn't support -s (--sloppy)

[Chuck Lever]

On Apr 25, 2008, at 4:11 AM, Steinar H. Gunderson wrote:
> Hi,
>
> Another user-reported regression. -s used to work, but since 1.1.2  
> it does
> not, probably due to the text-based interface somehow:
>
>  fugl:~> sudo mount.nfs 10.0.0.10:/store /store -s -o rw,asdfasdf
>  mount.nfs: an incorrect mount option was specified


It's not exactly clear what the "sloppy" option is supposed to allow.   
We are trying to figure out right now precisely how this should work.

But before complaining too loudly about text-based mounts, please  
remember that there was no specification for the mount.nfs command and  
mount system call interface except for a 15 year old man page.  We had  
to do something to move forward with IPv6 and RDMA transports; the  
legacy binary-only interface was simply inadequate.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: The text-based mount interface doesn't support -s (--sloppy)

[Steinar H. Gunderson]

On Fri, Apr 25, 2008 at 10:30:35AM -0400, Chuck Lever wrote:
> It's not exactly clear what the "sloppy" option is supposed to allow.   
> We are trying to figure out right now precisely how this should work.

Well, in general it seems to ignore any new options that come into it. The
problem in question was -o grpid= that was coming in through autofs mounts
and was not too easy to remove for the user.

> But before complaining too loudly about text-based mounts, please  
> remember that there was no specification for the mount.nfs command and  
> mount system call interface except for a 15 year old man page.  We had  
> to do something to move forward with IPv6 and RDMA transports; the  
> legacy binary-only interface was simply inadequate.

Yes, I'm fully aware of that. (In particular, I'm waiting eagerly for IPv6;
RDMA is a bit out of my range still. :-) ) People seem to depend on a lot of
options behaving in a specific way, though.

/* Steinar */
-- 
Homepage: http://www.sesse.net/

Re: The text-based mount interface doesn't support -s (--sloppy)

[Chuck Lever]

On Apr 25, 2008, at 10:35 AM, Steinar H. Gunderson wrote:
> On Fri, Apr 25, 2008 at 10:30:35AM -0400, Chuck Lever wrote:
>> It's not exactly clear what the "sloppy" option is supposed to allow.
>> We are trying to figure out right now precisely how this should work.
>
> Well, in general it seems to ignore any new options that come into  
> it. The
> problem in question was -o grpid= that was coming in through autofs  
> mounts and was not too easy to remove for the user.

The grpid mount option is what triggered our earlier discussion of -- 
sloppy as well.

An expedient solution may be to tell the kernel mount option parser  
specifically to ignore these common automounter options, like grpid.   
Jeff, what do you think of that?

>> But before complaining too loudly about text-based mounts, please
>> remember that there was no specification for the mount.nfs command  
>> and
>> mount system call interface except for a 15 year old man page.  We  
>> had
>> to do something to move forward with IPv6 and RDMA transports; the
>> legacy binary-only interface was simply inadequate.
>
> Yes, I'm fully aware of that. (In particular, I'm waiting eagerly  
> for IPv6;
> RDMA is a bit out of my range still. :-) ) People seem to depend on  
> a lot of
> options behaving in a specific way, though.

Understood.  Having neither a specification, a unit test suite, nor  
any strong sense of history on the mailing list (ie not having a grip  
on most use cases) means we are shooting blind in this case.

There will be some pain.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: The text-based mount interface doesn't support -s (--sloppy)

[Jeff Layton]

On Fri, 25 Apr 2008 10:50:09 -0400
Chuck Lever <chuck.lever@oracle.com> wrote:

> On Apr 25, 2008, at 10:35 AM, Steinar H. Gunderson wrote:
> > On Fri, Apr 25, 2008 at 10:30:35AM -0400, Chuck Lever wrote:
> >> It's not exactly clear what the "sloppy" option is supposed to allow.
> >> We are trying to figure out right now precisely how this should work.
> >
> > Well, in general it seems to ignore any new options that come into  
> > it. The
> > problem in question was -o grpid= that was coming in through autofs  
> > mounts and was not too easy to remove for the user.
> 
> The grpid mount option is what triggered our earlier discussion of -- 
> sloppy as well.
> 
> An expedient solution may be to tell the kernel mount option parser  
> specifically to ignore these common automounter options, like grpid.   
> Jeff, what do you think of that?
> 

That might reduce the pain for now...

I tend to think the big problem is people sharing autofs maps between
different OS's. It's hard to predict what options we might see that are
valid on another OS. We really need to define what the sloppy flag
means and how it behaves. It's a reasonably safe assumption that autofs
will use it, so hooking that up is probably the best solution.

Personally, I like the idea of just adding a "sloppy" mount option and
making "-s" add it to the string. When someone adds that option, the
kernel could just skip over options it doesn't recognize. When it's not
present, then it would fail on any unrecognized options.

This might mean that we need to have the kernel parser do more than one
pass over the string though. Once to look for the sloppy option, and
again to parse the others. This is not such a bad thing, IMO...there
are some other options that can get clobbered depending on order.

For instance, if retrans or timeo is parsed before "tcp" those options
can get overwritten. We may end up needing a multi-pass parser anyway...

-- 
Jeff Layton <jlayton@redhat.com>

Re: The text-based mount interface doesn't support -s (--sloppy)

[Chuck Lever]

On Apr 25, 2008, at 11:03 AM, Jeff Layton wrote:
> On Fri, 25 Apr 2008 10:50:09 -0400
> Chuck Lever <chuck.lever@oracle.com> wrote:
>
>> On Apr 25, 2008, at 10:35 AM, Steinar H. Gunderson wrote:
>>> On Fri, Apr 25, 2008 at 10:30:35AM -0400, Chuck Lever wrote:
>>>> It's not exactly clear what the "sloppy" option is supposed to  
>>>> allow.
>>>> We are trying to figure out right now precisely how this should  
>>>> work.
>>>
>>> Well, in general it seems to ignore any new options that come into
>>> it. The
>>> problem in question was -o grpid= that was coming in through autofs
>>> mounts and was not too easy to remove for the user.
>>
>> The grpid mount option is what triggered our earlier discussion of --
>> sloppy as well.
>>
>> An expedient solution may be to tell the kernel mount option parser
>> specifically to ignore these common automounter options, like grpid.
>> Jeff, what do you think of that?
>>
>
> That might reduce the pain for now...
>
> I tend to think the big problem is people sharing autofs maps between
> different OS's. It's hard to predict what options we might see that  
> are
> valid on another OS. We really need to define what the sloppy flag
> means and how it behaves. It's a reasonably safe assumption that  
> autofs
> will use it, so hooking that up is probably the best solution.
>
> Personally, I like the idea of just adding a "sloppy" mount option and
> making "-s" add it to the string. When someone adds that option, the
> kernel could just skip over options it doesn't recognize. When it's  
> not
> present, then it would fail on any unrecognized options.
>
> This might mean that we need to have the kernel parser do more than  
> one
> pass over the string though. Once to look for the sloppy option, and
> again to parse the others. This is not such a bad thing, IMO...there
> are some other options that can get clobbered depending on order.

The mount.nfs command can easily guarantee that the "sloppy" option  
comes first.  It might be a nice added flexibility to allow the parser  
to switch from strict to sloppy mode in the middle of the option string.

> For instance, if retrans or timeo is parsed before "tcp" those options
> can get overwritten. We may end up needing a multi-pass parser  
> anyway...

The parser can be made more careful about how those options are handled.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: The text-based mount interface doesn't support -s (--sloppy)

[Jeff Layton]

On Fri, 25 Apr 2008 11:17:39 -0400
Chuck Lever <chuck.lever@oracle.com> wrote:

> On Apr 25, 2008, at 11:03 AM, Jeff Layton wrote:
> > On Fri, 25 Apr 2008 10:50:09 -0400
> > Chuck Lever <chuck.lever@oracle.com> wrote:
> >
> >> On Apr 25, 2008, at 10:35 AM, Steinar H. Gunderson wrote:
> >>> On Fri, Apr 25, 2008 at 10:30:35AM -0400, Chuck Lever wrote:
> >>>> It's not exactly clear what the "sloppy" option is supposed to  
> >>>> allow.
> >>>> We are trying to figure out right now precisely how this should  
> >>>> work.
> >>>
> >>> Well, in general it seems to ignore any new options that come into
> >>> it. The
> >>> problem in question was -o grpid= that was coming in through autofs
> >>> mounts and was not too easy to remove for the user.
> >>
> >> The grpid mount option is what triggered our earlier discussion of --
> >> sloppy as well.
> >>
> >> An expedient solution may be to tell the kernel mount option parser
> >> specifically to ignore these common automounter options, like grpid.
> >> Jeff, what do you think of that?
> >>
> >
> > That might reduce the pain for now...
> >
> > I tend to think the big problem is people sharing autofs maps between
> > different OS's. It's hard to predict what options we might see that  
> > are
> > valid on another OS. We really need to define what the sloppy flag
> > means and how it behaves. It's a reasonably safe assumption that  
> > autofs
> > will use it, so hooking that up is probably the best solution.
> >
> > Personally, I like the idea of just adding a "sloppy" mount option and
> > making "-s" add it to the string. When someone adds that option, the
> > kernel could just skip over options it doesn't recognize. When it's  
> > not
> > present, then it would fail on any unrecognized options.
> >
> > This might mean that we need to have the kernel parser do more than  
> > one
> > pass over the string though. Once to look for the sloppy option, and
> > again to parse the others. This is not such a bad thing, IMO...there
> > are some other options that can get clobbered depending on order.
> 
> The mount.nfs command can easily guarantee that the "sloppy" option  
> comes first.  It might be a nice added flexibility to allow the parser  
> to switch from strict to sloppy mode in the middle of the option string.
> 

That's fine with me, but we'll definitely need to document that. People
usu assume that the order of mount options don't matter.

> > For instance, if retrans or timeo is parsed before "tcp" those options
> > can get overwritten. We may end up needing a multi-pass parser  
> > anyway...
> 
> The parser can be made more careful about how those options are handled.
> 

Yep. That's another option (and is probably easier to implement too).

-- 
Jeff Layton <jlayton@redhat.com>

Re: The text-based mount interface doesn't support -s (--sloppy)

[Chuck Lever]

On Apr 25, 2008, at 11:42 AM, Jeff Layton wrote:
> On Fri, 25 Apr 2008 11:17:39 -0400
> Chuck Lever <chuck.lever@oracle.com> wrote:
>> On Apr 25, 2008, at 11:03 AM, Jeff Layton wrote:
>>> On Fri, 25 Apr 2008 10:50:09 -0400
>>> Chuck Lever <chuck.lever@oracle.com> wrote:
>>>> On Apr 25, 2008, at 10:35 AM, Steinar H. Gunderson wrote:
>>>>> On Fri, Apr 25, 2008 at 10:30:35AM -0400, Chuck Lever wrote:
>>>>>> It's not exactly clear what the "sloppy" option is supposed to
>>>>>> allow.
>>>>>> We are trying to figure out right now precisely how this should
>>>>>> work.
>>>>>
>>>>> Well, in general it seems to ignore any new options that come into
>>>>> it. The
>>>>> problem in question was -o grpid= that was coming in through  
>>>>> autofs
>>>>> mounts and was not too easy to remove for the user.
>>>>
>>>> The grpid mount option is what triggered our earlier discussion  
>>>> of --
>>>> sloppy as well.
>>>>
>>>> An expedient solution may be to tell the kernel mount option parser
>>>> specifically to ignore these common automounter options, like  
>>>> grpid.
>>>> Jeff, what do you think of that?
>>>>
>>>
>>> That might reduce the pain for now...
>>>
>>> I tend to think the big problem is people sharing autofs maps  
>>> between
>>> different OS's. It's hard to predict what options we might see that
>>> are
>>> valid on another OS. We really need to define what the sloppy flag
>>> means and how it behaves. It's a reasonably safe assumption that
>>> autofs
>>> will use it, so hooking that up is probably the best solution.
>>>
>>> Personally, I like the idea of just adding a "sloppy" mount option  
>>> and
>>> making "-s" add it to the string. When someone adds that option, the
>>> kernel could just skip over options it doesn't recognize. When it's
>>> not
>>> present, then it would fail on any unrecognized options.
>>>
>>> This might mean that we need to have the kernel parser do more than
>>> one
>>> pass over the string though. Once to look for the sloppy option, and
>>> again to parse the others. This is not such a bad thing, IMO...there
>>> are some other options that can get clobbered depending on order.
>>
>> The mount.nfs command can easily guarantee that the "sloppy" option
>> comes first.  It might be a nice added flexibility to allow the  
>> parser
>> to switch from strict to sloppy mode in the middle of the option  
>> string.
>>
>
> That's fine with me, but we'll definitely need to document that.  
> People
> usu assume that the order of mount options don't matter.
>
>>> For instance, if retrans or timeo is parsed before "tcp" those  
>>> options
>>> can get overwritten. We may end up needing a multi-pass parser
>>> anyway...
>>
>> The parser can be made more careful about how those options are  
>> handled.
>>
>
> Yep. That's another option (and is probably easier to implement too).

I have some patches now that address both these problems.  I'll do  
some testing and post on Monday.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com