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
