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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Apr 25, 2008, at 11:42 AM, Jeff Layton wrote:
On Fri, 25 Apr 2008 11:17:39 -0400
Chuck Lever <chuck.lever@xxxxxxxxxx> 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@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux