Message-ID: <20251022185214.abdbkp7eqmcrnbhx@pali>
Date: Wed, 22 Oct 2025 20:52:14 +0200
From: Pali Rohár <pali@...nel.org>
To: Namjae Jeon <linkinjeon@...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 Wednesday 22 October 2025 11:13:50 Namjae Jeon wrote:
> 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.

I'm really sorry, I did not mean it in that way. I just wanted to point
that year is a very long period and unexpected things could happen.
Nothing against your or any others effort.

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