Re: [RFC PATCH] Legacy mount option "sloppy" support

[Ian Kent <raven@themaw.net>]

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


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.


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.


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.


It might end up we have to revisit it but at least if that's the case

we should have more detailed use cases that are current.


Ian