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

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.

Quoted 2 lines · Chuck Lever

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.

Quoted 5 lines

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.

Quoted 8 lines · Steinar H. Gunderson

Quoted 2 lines · Chuck Lever

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?

Quoted 10 lines · On Fri, 25 Apr 2008 10:50:09 -0400 Chuck Lever <[email protected]> wrote:

Quoted 8 lines · Steinar H. Gunderson

Quoted 2 lines · Chuck Lever

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.

Quoted 7 lines

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...

Quoted 39 lines · Jeff Layton

Quoted 12 lines · On Fri, 25 Apr 2008 10:50:09 -0400 Chuck Lever <[email protected]> wrote:

Quoted 10 lines · Steinar H. Gunderson

Quoted 4 lines · Chuck Lever

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.

Quoted 7 lines

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.

Quoted 5 lines

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.

Quoted 3 lines

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.

Quoted 45 lines · On Fri, 25 Apr 2008 11:17:39 -0400 Chuck Lever <[email protected]> wrote:

Quoted 38 lines · Jeff Layton

Quoted 12 lines · On Fri, 25 Apr 2008 10:50:09 -0400 Chuck Lever <[email protected]> wrote:

Quoted 10 lines · Steinar H. Gunderson

Quoted 4 lines · Chuck Lever

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.

Quoted 7 lines

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.

Quoted 5 lines

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.

Quoted 4 lines

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.

Quoted 6 lines

Quoted 3 lines

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).