[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKYAXd-EZ1i9CeQ3vUCXgzQ7HTJdd-eeXRq3=iUaSTkPLbJLCg@mail.gmail.com>
Date: Tue, 21 Oct 2025 10:49:48 +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 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.
>
> 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.
>
> 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.
>
> 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