Re: [PATCH 00/11] ntfsplus: ntfs filesystem remake

["Pali Rohár" <pali@kernel.org>]

On Tuesday 21 October 2025 10:49:48 Namjae Jeon wrote:
> On Tue, Oct 21, 2025 at 3:33 AM Pali Rohár <pali@kernel.org> wrote:
> >
> > Hello,
> Hi Pali,
> >
> > Do you have a plan, what should be the future of the NTFS support in
> > Linux? Because basically this is a third NTFS driver in recent years
> > and I think it is not a good idea to replace NTFS driver every decade by
> > a new different implementation.
> Our product is currently using ntfsplus without any issues, but we plan to
> provide support for the various issues that are reported from users or
> developers once it is merged into the mainline kernel.
> This is very basic, but the current ntfs3 has not provided this support
> for the last four years.
> After ntfsplus was merged, our next step will be to implement full journal
> support. Our ultimate goal is to provide stable NTFS support in Linux,
> utilities support included fsck(ntfsprogs-plus) and journaling.

One important thing here is that all those drivers are implementing
support for same filesystem. So theoretically they should be equivalent
(modulo bugs and missing features).

So basically the userspace ntfs fs utils should work with any of those
drivers and also should be compatible with Windows ntfs.sys driver.
And therefore independent of the used kernel driver.

It would be really nice to have working fsck utility for ntfs. I hope
that we would not have 3 ntfs mkfs/fsck tools from 3 different project
and every one would have different set of bugs or limitations.

> >
> > Is this new driver going to replace existing ntfs3 driver? Or should it
> > live side-by-side together with ntfs3?
> Currently, it is the latter. I think the two drivers should compete.
> A ntfs driver that users can reliably use for ntfs in their
> products is what should be the one that remains.
> Four years ago, ntfs3 promised to soon release the full journal and
> public utilities support that were in their commercial version.
> That promise hasn't been kept yet, Probably, It would not be easy for
> a company that sells a ntfs driver commercially to open some or all sources.
> That's why I think we need at least competition.

I understand it. It is not really easy.

Also same thing can happen with your new ntfsplus. Nobody knows what
would happen in next one or two years.

> >
> > If this new driver is going to replace ntfs3 then it should provide same
> > API/ABI to userspace. For this case at least same/compatible mount
> > options, ioctl interface and/or attribute features (not sure what is
> > already supported).
> Sure, If ntfsplus replace ntfs3, it will support them.
> >
> > You wrote that ntfsplus is based on the old ntfs driver. How big is the
> > diff between old ntfs and new ntfsplus driver? If the code is still
> > same, maybe it would be better to call it ntfs as before and construct
> > commits in a way which will first "revert the old ntfs driver" and then
> > apply your changes on top of it (like write feature, etc..)?
> I thought this patch-set was better because a lot of code clean-up
> was done, resulting in a large diff, and the old ntfs was removed.
> I would like to proceed with the current set of patches rather than
> restructuring the patchset again.

Sure. In the current form it looks to be more readable and easier for
review.

But I think that more developers could be curious how similar is the new
ntfsplus to the old removed ntfs. And in the form of revert + changes it
is easier to see what was changed, what was fixed and what new developed.

I'm just thinking, if the code has really lot of common parts, maybe it
would make sense to have it in git in that "big revert + new changes"
form?

> >
> > For mount options, for example I see that new driver does not use
> > de-facto standard iocharset= mount option like all other fs driver but
> > instead has nls= mount option. This should be fixed.
> Okay, I will fix it on the next version.
> >
> > Pali
> Thank you for your review:)