On Tue, Apr 04, 2023 at 09:52:27AM +0800, Ian Kent wrote: > On 3/4/23 21:08, Christian Brauner wrote: > > On Wed, Mar 29, 2023 at 09:03:51AM +0800, Ian Kent wrote: > > > On 29/3/23 02:48, Karel Zak wrote: > > > > On Fri, Mar 24, 2023 at 01:39:09PM +0800, Ian Kent wrote: > > > > > Karel do you find what I'm saying is accurate? > > > > > Do you think we will be able to get rid of the sloppy option over > > > > > time with the move to use the mount API? > > > > The question is what we're talking about :-) > > > > > > > > For mount(8) and libmount, there is nothing like the "sloppy" mount option. > > > > > > > > If you use it in your fstab or as "mount -o sloppy" on the command line, > > > > then it's used as any other fs-specific mount option; the library copies > > > > the string to mount(2) or fsconfig(2) syscall. The library has no clue > > > > what the string means (it's the same as "mount -o foobar"). > > > Which is what the problem really is. > > > > > > > > > If anyone uses this option with a file system that has previously > > > > > > allowed it then mounts fail if it isn't handled properly. Then the > > > > > > intended purpose of it is irrelevant because it causes a fail. > > > > > > > > > I guess the notion of ignoring it for fsconfig(), assuming it isn't > > > > > > actually needed for the option handling, might not be a viable idea > > > > > > ... although I haven't actually added that to fsconfig(), I probably > > > > > > should add that to this series. > > > > > > > > > But first the question of whether the option is actually needed anymore > > > > > > by those that allow it needs to be answered. > > > > > > > > > In case anyone has forgotten it was introduced because, at one time > > > > > > different OSes supported slightly different options for for the same > > > > > > thing and one could not include multiple options for the same thing > > > > > > in automount map entries without causing the mount to fail. > > > > > > > > > So we also need to answer, is this option conflict still present for > > > > > > any of the file systems that allow it, currently nfs, cifs and ntfs > > > > > > (I'll need to look up the ntfs maintainer but lets answer this for > > > > > > nfs and cifs first). > > > > > > > > > If it isn't actually needed ignoring it in fsconfig() (a deprecation > > > > > > warning would be in order) and eventually getting rid of it would be > > > > > > a good idea, yes? > > Yes, I think this is a good idea. > > The whole reason for this mount option seems a bit hacky tbh so getting > > rid of it would be great. > > Thanks for thinking about this Christian. > > It is something that has concerned me for a long time now. > > > I know the impression that people get is that it's hacky and it's > > accurate to an extent but there was real need and value for it at > > one point (although it was around before my time). No, I get it and I understand that there was a rationale behind it. > > > But now we get tripped up because trying to get rid of it causes > > the problem of the option itself not working which tends to obscure > > the actual use case of users. Yeah, agreed. > > > I think the change to use the mount API is the best opportunity we've > > had to clean this up in forever, particularly since the mount API > > makes it particularly hard to continue to use it. Agreed. > > > I'm still thinking about it and I'll post an updated patch and > > accompanying discussion at some point. At the very least we need a > > clear upstream position on it to allow those of us with customers > > that think they need it to pass on the deprecation notice and reasoning. I think that "sloppy" is exactly what it is "sloppy" so if we can purge it from the new mount api then we should do it.
