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