On Tuesday 14 September 2021 19:33:32 Konstantin Komarov wrote:

On 12.09.2021 22:48, Kari Argillander wrote:

quoted

On Sun, Sep 12, 2021 at 08:43:47PM +0200, Pali Rohár wrote:

quoted

Hello!

On Friday 10 September 2021 15:19:16 Kari Argillander wrote:

quoted

10.09.2021 14.23 Marcos Mello (marcosfrm@gmail.com) wrote:

quoted

Hi, sorry email you directly, but this mailing list thing is cryptic
to me.

I CC also lists to this so now everyone knows. Also CC couple
others who might be interested to talk about this.

quoted

I was reading your patches cleaning up ntfs3 documentation and
realized some mount options diverge from NTFS-3G. This will make
udisks people unhappy.

If you still have to specify which fs driver want to use (ntfs, ntfs-3g,
ntfs3). So each software needs to be adjusted if want to start using
different fs driver even when mount options are same. So I think there
are no big issues that different fs driver are using different mount
options.

quoted

This is true. They also diverge from the current NTFS driver. We have
talk about it a little bit and before ntfs driver can go out from kernel we
need to support those flags or at least some. udisk currently does only
support NTFS-3G and it does not support kernel ntfs driver. So nothing
will change.

I also agree that we should check mount options from ntfs-3g and maybe
implement them in. Maybe we can just take some mount options with
deprecated and print that this option is meant to use with ntfs-3g please
note that this is kernel ntfs3 driver or something. It would still work for
users. Ntfs-3g contains imo lot of unnecessary flags. Kernel community
would probably not want to maintain so large list of different options.

Mount options which makes sense could be implemented. Just somebody
needs to do it.

quoted

Ntfs-3g group also has acounted problems because they say that you
should example use "big_writes", but not everyone does and that drops
performance. Driver should work good way by default.

I agree. Mount option which is just a hack because of some poor
implementation should not be introduced. Instead bugs should be fixed.
Also it applies for "performance issues" which do not change behavior of
fs operations (i.e. read() / write() operations do same thing on raw
disk).

quoted

And only if there
is really demand there should be real mount option. But like I said, maybe
we should add "fake" ntfs-3g options so if some user change to use ntfs3
it will be pretty painless.

This really should not be in kernel. You can implement userspace mount
helper which translates "legacy" ntfs-3g options into "correct" kernel
options. /bin/mount already supports these helpers / wrappers... Just
people do not know much about them.

Good to know. Thanks for this info.

quoted

quoted

quoted

NTFS-3G options:
https://github.com/tuxera/ntfs-3g/blob/edge/src/ntfs-3g.8.in

UDISKS default and allowed options:
https://github.com/storaged-project/udisks/blob/master/data/builtin_mount_options.conf

For example, windows_names is not supported in ntfs3 and
show_sys_files should probably be an alias to showmeta.

Imo windows_names is good option. There is so many users who just
want to use this with dual boot. That is why I think best option would
be windows_compatible or something. Then we do everything to user
not screw up things with disk and that when he checks disk with windows
everything will be ok. This option has to also select ignore_case.

But right now we are horry to take every mount option away what we won't
need. We can add options later. And this is so early that we really cannot
think so much how UDSIKS threats ntfs-3g. It should imo not be problem
for them to also support for ntfs3 with different options.

This is something which needs to be handled and fixed systematically. We
have at least 5 filesystems in kernel (bonus question, try to guess
them :D) which support some kind/parts of "windows nt" functionality.
And it is pain if every one fs would use different option for
similar/same functionality.

Hopefully we can tackle this issue someday. But we will have lot of
deprecated options if we tackle this, but it is good thing and should
done in some point. I will answer your bonus question when we can throw
away one of those drivers.

quoted

quoted

quoted

Also, is NTFS-3G locale= equivalent to ntfs3 nls=?

Pretty much. It is now called iocharset and nls will be deprecated.
This is work towards that every Linux kernel filesystem driver which
depends on this option will be same name. Ntfs-3g should also use
it.

iocharset= is what most fs supports. Just few name this option as nls=
and for consistency I preparing patches which adds iocharset= alias for
all kernel filesystems. nls= (for those few fs) stay supported as legacy
alias for iocharset=.

Kari, now I'm thinking about nls= in new ntfs3 kernel driver. It is
currently being marked as deprecated. Does it really make sense to
introduce in new fs already deprecated option? Now when final linux
version which introduce this driver was not released yet, we can simply
drop (= do not introduce this option). 

We have discuss this earlier [1]. I think Konstantin can really decide
this one. I think it is he "rights" like was kinda chosen that ntfs64
can live in kernel because Paragon say some of they customers need it. I
have after that include big warning about using it. Because thing is
that if Paragon will not support it nobady will and someone will just
drop support for it.

Marking some option to deprecated is just 4 trivial line of code. I also
did not even bother to documented it. I can live with that if we won't
have this option but it can be little easier to some if we have that.
And I really do not mind if 4 extra line code inside structs. So my vote
is for deprecated.

Konstantion: Can you give us your opionion on this one?

Before answering I want to know: is it easy to remove deprecated option
from code? I read different opinions in this thread.

Removal is a problem in general as kernel should provide backward
compatibility with features and APIs which were already released.

If removal will be easy, then I vote for deprecated option.
Supporting familiar mount options will help in transition.
After some time (one or two kernel releases?) this support can be dropped.

If removal will be hard, then better to remove now.
It will make things a bit harder for user, but it's better, than
having a list of deprecated options, that do nothing and will be there forever.

quoted

[1]: https://lore.kernel.org/ntfs3/20210819095527.w4uv6gzuyaotxjpe@pali/ (local)

quoted

But after release, there would be no easy way to remove it. Adding a
new option can be done at any time later easily...

I think if something is has been deprecated from the start we can just
drop it when ever we want, but maybe we should add comment there and
just choose that first release in 2027 will not anymore have this
option. I recommend that you made this kind of thing in your patch
series too. XFS has commented nicely that we really drop this in x date.
This way decision is made before and then even janitor can come and
clean it when that time comes.

  Argillander

quoted

quoted

quoted

Thank you a lot for all the work put into ntfs3!

Marcos