Message-ID: <CAKYAXd9mun=jTbL2J8-d5Zfe8QuwCT-eM6c3p1Td05uxSE2yFQ@mail.gmail.com>
Date: Thu, 23 Oct 2025 07:32:45 +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 Thu, Oct 23, 2025 at 3:52 AM Pali Rohár <pali@...nel.org> wrote:
>
> 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.
I apologize for the misunderstanding. Thank you for clarifying that for me.

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