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