Message-ID: <CAKYAXd8iexxzsiEzBwyp6fWazDFME_ad4LUJdzJQFM6KjBOe=g@mail.gmail.com>
Date: Wed, 22 Oct 2025 11:13:50 +0900
From: Namjae Jeon <linkinjeon@...nel.org>
To: Pali Rohár <pali@...nel.org>
Cc: viro@...iv.linux.org.uk, brauner@...nel.org, hch@...radead.org, hch@....de, 
	tytso@....edu, willy@...radead.org, jack@...e.cz, djwong@...nel.org, 
	josef@...icpanda.com, sandeen@...deen.net, rgoldwyn@...e.com, 
	xiang@...nel.org, dsterba@...e.com, ebiggers@...nel.org, neil@...wn.name, 
	amir73il@...il.com, linux-fsdevel@...r.kernel.org, 
	linux-kernel@...r.kernel.org, iamjoonsoo.kim@....com, cheol.lee@....com, 
	jay.sim@....com, gunho.lee@....com
Subject: Re: [PATCH 00/11] ntfsplus: ntfs filesystem remake

On Wed, Oct 22, 2025 at 7:19 AM Pali Rohár <pali@...nel.org> wrote:
>
> On Tuesday 21 October 2025 10:49:48 Namjae Jeon wrote:
> > On Tue, Oct 21, 2025 at 3:33 AM Pali Rohár <pali@...nel.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.
Since I publicly mentioned adding write support to ntfs driver, I have devoted
a great deal of time and effort to fulfilling that while working on other tasks
in parallel. Your comment seems to undermine all the effort I have done
over the 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:)

Powered by blists - more mailing lists