Introduction
============

The NTFS filesystem[1] still remains the default filesystem for Windows
and The well-maintained NTFS driver in the Linux kernel enhances
interoperability with Windows devices, making it easier for Linux users
to work with NTFS-formatted drives. Currently, ntfs support in Linux was
the long-neglected NTFS Classic (read-only), which has been removed from
the Linux kernel, leaving the poorly maintained ntfs3. ntfs3 still has
many problems and is poorly maintained, so users and distributions are
still using the old legacy ntfs-3g.


What is ntfsplus?
=================

The remade ntfs called ntfsplus is an implementation that supports write
and the essential requirements(iomap, no buffer-head, utilities, xfstests
test result) based on read-only classic NTFS.
The old read-only ntfs code is much cleaner, with extensive comments,
offers readability that makes understanding NTFS easier. This is why
ntfsplus was developed on old read-only NTFS base.
The target is to provide current trends(iomap, no buffer head, folio),
enhanced performance, stable maintenance, utility support including fsck.


Key Features
============

- Write support:
   Implement write support on classic read-only NTFS. Additionally,
   integrate delayed allocation to enhance write performance through
   multi-cluster allocation and minimized fragmentation of cluster bitmap.

- Switch to using iomap:
   Use iomap for buffered IO writes, reads, direct IO, file extent mapping,
   readpages, writepages operations.

- Stop using the buffer head:
   The use of buffer head in old ntfs and switched to use folio instead.
   As a result, CONFIG_BUFFER_HEAD option enable is removed in Kconfig also.

- Public utilities include fsck[2]:
   While ntfs-3g includes ntfsprogs as a component, it notably lacks
   the fsck implementation. So we have launched a new ntfs utilitiies
   project called ntfsprogs-plus by forking from ntfs-3g after removing
   unnecessary ntfs fuse implementation. fsck.ntfs can be used for ntfs
   testing with xfstests as well as for recovering corrupted NTFS device.

- Performance Enhancements:

   - ntfsplus vs. ntfs3:

     * Performance was benchmarked using iozone with various chunk size.
        - In single-thread(1T) write tests, ntfsplus show approximately
          3~5% better performance.
        - In multi-thread(4T) write tests, ntfsplus show approximately
          35~110% better performance.
        - Read throughput is identical for both ntfs implementations.

     1GB file      size:4096           size:16384           size:65536
     MB/sec   ntfsplus | ntfs3    ntfsplus | ntfs3    ntfsplus | ntfs3
     ─────────────────────────────────────────────────────────────────
     read          399 | 399           426 | 424           429 | 430
     ─────────────────────────────────────────────────────────────────
     write(1T)     291 | 276           325 | 305           333 | 317
     write(4T)     105 | 50            113 | 78            114 | 99.6


     * File list browsing performance. (about 12~14% faster)

                  files:100000        files:200000        files:400000
     Sec      ntfsplus | ntfs3    ntfsplus | ntfs3    ntfsplus | ntfs3
     ─────────────────────────────────────────────────────────────────
     ls -lR       7.07 | 8.10        14.03 | 16.35       28.27 | 32.86


     * mount time.

             parti_size:1TB      parti_size:2TB      parti_size:4TB
     Sec      ntfsplus | ntfs3    ntfsplus | ntfs3    ntfsplus | ntfs3
     ─────────────────────────────────────────────────────────────────
     mount        0.38 | 2.03         0.39 | 2.25         0.70 | 4.51

   The following are the reasons why ntfsplus performance is higher
    compared to ntfs3:
     - Use iomap aops.
     - Delayed allocation support.
     - Optimize zero out for newly allocated clusters.
     - Optimize runlist merge overhead with small chunck size.
     - pre-load mft(inode) blocks and index(dentry) blocks to improve
       readdir + stat performance.
     - Load lcn bitmap on background.

- Stability improvement:
   a. Pass more xfstests tests:
      ntfsplus passed 287 tests, significantly higher than ntfs3's 218.
      ntfsplus implement fallocate, idmapped mount and permission, etc,
      resulting in a significantly high number of xfstests passing compared
      to ntfs3.
   b. Bonnie++ issue[3]:
      The Bonnie++ benchmark fails on ntfs3 with a "Directory not empty"
      error during file deletion. ntfs3 currently iterates directory
      entries by reading index blocks one by one. When entries are deleted
      concurrently, index block merging or entry relocation can cause
      readdir() to skip some entries, leaving files undeleted in
      workloads(bonnie++) that mix unlink and directory scans.
      ntfsplus implement leaf chain traversal in readdir to avoid entry skip
      on deletion.

- Journaling support:
   ntfs3 does not provide full journaling support. It only implement journal
   replay[4], which in our testing did not function correctly. My next task
   after upstreaming will be to add full journal support to ntfsplus.


The feature comparison summary
==============================

Feature                               ntfsplus   ntfs3
===================================   ========   ===========
Write support                         Yes        Yes
iomap support                         Yes        No
No buffer head                        Yes        No
Public utilities(mkfs, fsck, etc.)    Yes        No
xfstests passed                       287        218
Idmapped mount                        Yes        No
Delayed allocation                    Yes        No
Bonnie++                              Pass       Fail
Journaling                            Planned    Inoperative
===================================   ========   ===========

References
==========
[1] https://en.wikipedia.org/wiki/NTFS
[2] https://github.com/ntfsprogs-plus/ntfsprogs-plus
[3] https://lore.kernel.org/ntfs3/CAOZgwEd7NDkGEpdF6UQTcbYuupDavaHBoj4WwTy3Qe4Bqm6V0g@mail.gmail.com/
[4] https://marc.info/?l=linux-fsdevel&m=161738417018673&q=mbox


Namjae Jeon (11):
  ntfsplus: in-memory, on-disk structures and headers
  ntfsplus: add super block operations
  ntfsplus: add inode operations
  ntfsplus: add directory operations
  ntfsplus: add file operations
  ntfsplus: add iomap and address space operations
  ntfsplus: add attrib operatrions
  ntfsplus: add runlist handling and cluster allocator
  ntfsplus: add reparse and ea operations
  ntfsplus: add misc operations
  ntfsplus: add Kconfig and Makefile

 fs/Kconfig                |    1 +
 fs/Makefile               |    1 +
 fs/ntfsplus/Kconfig       |   45 +
 fs/ntfsplus/Makefile      |   18 +
 fs/ntfsplus/aops.c        |  631 +++++
 fs/ntfsplus/aops.h        |   92 +
 fs/ntfsplus/attrib.c      | 5373 +++++++++++++++++++++++++++++++++++++
 fs/ntfsplus/attrib.h      |  159 ++
 fs/ntfsplus/attrlist.c    |  276 ++
 fs/ntfsplus/attrlist.h    |   21 +
 fs/ntfsplus/bitmap.c      |  193 ++
 fs/ntfsplus/bitmap.h      |   90 +
 fs/ntfsplus/collate.c     |  173 ++
 fs/ntfsplus/collate.h     |   37 +
 fs/ntfsplus/compress.c    | 1565 +++++++++++
 fs/ntfsplus/dir.c         | 1226 +++++++++
 fs/ntfsplus/dir.h         |   33 +
 fs/ntfsplus/ea.c          |  712 +++++
 fs/ntfsplus/ea.h          |   25 +
 fs/ntfsplus/file.c        | 1056 ++++++++
 fs/ntfsplus/index.c       | 2114 +++++++++++++++
 fs/ntfsplus/index.h       |  127 +
 fs/ntfsplus/inode.c       | 3705 +++++++++++++++++++++++++
 fs/ntfsplus/inode.h       |  354 +++
 fs/ntfsplus/layout.h      | 2288 ++++++++++++++++
 fs/ntfsplus/lcnalloc.c    |  993 +++++++
 fs/ntfsplus/lcnalloc.h    |  127 +
 fs/ntfsplus/logfile.c     |  773 ++++++
 fs/ntfsplus/logfile.h     |  316 +++
 fs/ntfsplus/mft.c         | 2630 ++++++++++++++++++
 fs/ntfsplus/mft.h         |   93 +
 fs/ntfsplus/misc.c        |  221 ++
 fs/ntfsplus/misc.h        |  218 ++
 fs/ntfsplus/mst.c         |  195 ++
 fs/ntfsplus/namei.c       | 1606 +++++++++++
 fs/ntfsplus/ntfs.h        |  172 ++
 fs/ntfsplus/ntfs_iomap.c  |  704 +++++
 fs/ntfsplus/ntfs_iomap.h  |   22 +
 fs/ntfsplus/reparse.c     |  550 ++++
 fs/ntfsplus/reparse.h     |   15 +
 fs/ntfsplus/runlist.c     | 1995 ++++++++++++++
 fs/ntfsplus/runlist.h     |   91 +
 fs/ntfsplus/super.c       | 2716 +++++++++++++++++++
 fs/ntfsplus/unistr.c      |  471 ++++
 fs/ntfsplus/upcase.c      |   73 +
 fs/ntfsplus/volume.h      |  241 ++
 include/uapi/linux/ntfs.h |   23 +
 47 files changed, 34560 insertions(+)
 create mode 100644 fs/ntfsplus/Kconfig
 create mode 100644 fs/ntfsplus/Makefile
 create mode 100644 fs/ntfsplus/aops.c
 create mode 100644 fs/ntfsplus/aops.h
 create mode 100644 fs/ntfsplus/attrib.c
 create mode 100644 fs/ntfsplus/attrib.h
 create mode 100644 fs/ntfsplus/attrlist.c
 create mode 100644 fs/ntfsplus/attrlist.h
 create mode 100644 fs/ntfsplus/bitmap.c
 create mode 100644 fs/ntfsplus/bitmap.h
 create mode 100644 fs/ntfsplus/collate.c
 create mode 100644 fs/ntfsplus/collate.h
 create mode 100644 fs/ntfsplus/compress.c
 create mode 100644 fs/ntfsplus/dir.c
 create mode 100644 fs/ntfsplus/dir.h
 create mode 100644 fs/ntfsplus/ea.c
 create mode 100644 fs/ntfsplus/ea.h
 create mode 100644 fs/ntfsplus/file.c
 create mode 100644 fs/ntfsplus/index.c
 create mode 100644 fs/ntfsplus/index.h
 create mode 100644 fs/ntfsplus/inode.c
 create mode 100644 fs/ntfsplus/inode.h
 create mode 100644 fs/ntfsplus/layout.h
 create mode 100644 fs/ntfsplus/lcnalloc.c
 create mode 100644 fs/ntfsplus/lcnalloc.h
 create mode 100644 fs/ntfsplus/logfile.c
 create mode 100644 fs/ntfsplus/logfile.h
 create mode 100644 fs/ntfsplus/mft.c
 create mode 100644 fs/ntfsplus/mft.h
 create mode 100644 fs/ntfsplus/misc.c
 create mode 100644 fs/ntfsplus/misc.h
 create mode 100644 fs/ntfsplus/mst.c
 create mode 100644 fs/ntfsplus/namei.c
 create mode 100644 fs/ntfsplus/ntfs.h
 create mode 100644 fs/ntfsplus/ntfs_iomap.c
 create mode 100644 fs/ntfsplus/ntfs_iomap.h
 create mode 100644 fs/ntfsplus/reparse.c
 create mode 100644 fs/ntfsplus/reparse.h
 create mode 100644 fs/ntfsplus/runlist.c
 create mode 100644 fs/ntfsplus/runlist.h
 create mode 100644 fs/ntfsplus/super.c
 create mode 100644 fs/ntfsplus/unistr.c
 create mode 100644 fs/ntfsplus/upcase.c
 create mode 100644 fs/ntfsplus/volume.h
 create mode 100644 include/uapi/linux/ntfs.h

-- 
2.34.1

On Mon, Oct 20, 2025 at 11:07:38AM +0900, Namjae Jeon wrote:
> The feature comparison summary
> ==============================
> 
> Feature                               ntfsplus   ntfs3
> ===================================   ========   ===========
> Write support                         Yes        Yes
> iomap support                         Yes        No
> No buffer head                        Yes        No
> Public utilities(mkfs, fsck, etc.)    Yes        No
> xfstests passed                       287        218
> Idmapped mount                        Yes        No
> Delayed allocation                    Yes        No
> Bonnie++                              Pass       Fail
> Journaling                            Planned    Inoperative
> ===================================   ========   ===========

Having two implementations of the same is problematic but I think what
votes for ntfs+ is that it's using the current internal interfaces like
iomap and no buffer heads. I'm not familiar with recent ntfs3
development but it would be good to know if the API conversions are
planned at all.

There are many filesystems using the old interfaces and I think most of
them will stay like that. The config options BUFFER_HEAD and FS_IOMAP
make the distinction what people care about most. In case of ntfs it's
clearly for interoperability.

As a user I'd be interested in feature parity with ntfs3, eg. I don't
see the label ioctls supported but it's a minor thing. Ideally there's
one full featured implementation but I take it that it may not be
feasible to update ntfs3 so it's equivalent to ntfs+. As this is not a
native linux filesystem swapping the implementation can be fairly
transparent, depending only on the config options. The drawback is
losing the history of fixed bugs that may show up again.

We could do the same as when ntfs3 appeared, but back then it had
arguably better position as it brought full write support. Right now I
understand it more of as maintenance problem.

On Wednesday 22 October 2025 08:30:56 David Sterba wrote:
> On Mon, Oct 20, 2025 at 11:07:38AM +0900, Namjae Jeon wrote:
> > The feature comparison summary
> > ==============================
> > 
> > Feature                               ntfsplus   ntfs3
> > ===================================   ========   ===========
> > Write support                         Yes        Yes
> > iomap support                         Yes        No
> > No buffer head                        Yes        No
> > Public utilities(mkfs, fsck, etc.)    Yes        No
> > xfstests passed                       287        218
> > Idmapped mount                        Yes        No
> > Delayed allocation                    Yes        No
> > Bonnie++                              Pass       Fail
> > Journaling                            Planned    Inoperative
> > ===================================   ========   ===========
> 
> Having two implementations of the same is problematic but I think what
> votes for ntfs+ is that it's using the current internal interfaces like
> iomap and no buffer heads. I'm not familiar with recent ntfs3
> development but it would be good to know if the API conversions are
> planned at all.
> 
> There are many filesystems using the old interfaces and I think most of
> them will stay like that. The config options BUFFER_HEAD and FS_IOMAP
> make the distinction what people care about most. In case of ntfs it's
> clearly for interoperability.
> 
> As a user I'd be interested in feature parity with ntfs3, eg. I don't
> see the label ioctls supported but it's a minor thing. Ideally there's
> one full featured implementation but I take it that it may not be
> feasible to update ntfs3 so it's equivalent to ntfs+. As this is not a
> native linux filesystem swapping the implementation can be fairly
> transparent, depending only on the config options. The drawback is
> losing the history of fixed bugs that may show up again.

This drawback already happened at the time of switch from old ntfs to
ntfs3 driver. So I think that this is not a problem.

> We could do the same as when ntfs3 appeared, but back then it had
> arguably better position as it brought full write support. Right now I
> understand it more of as maintenance problem.

On Wed, Oct 22, 2025 at 3:31 PM David Sterba <dsterba@suse.cz> wrote:
>
> On Mon, Oct 20, 2025 at 11:07:38AM +0900, Namjae Jeon wrote:
> > The feature comparison summary
> > ==============================
> >
> > Feature                               ntfsplus   ntfs3
> > ===================================   ========   ===========
> > Write support                         Yes        Yes
> > iomap support                         Yes        No
> > No buffer head                        Yes        No
> > Public utilities(mkfs, fsck, etc.)    Yes        No
> > xfstests passed                       287        218
> > Idmapped mount                        Yes        No
> > Delayed allocation                    Yes        No
> > Bonnie++                              Pass       Fail
> > Journaling                            Planned    Inoperative
> > ===================================   ========   ===========
>
> Having two implementations of the same is problematic but I think what
> votes for ntfs+ is that it's using the current internal interfaces like
> iomap and no buffer heads. I'm not familiar with recent ntfs3
> development but it would be good to know if the API conversions are
> planned at all.
>
> There are many filesystems using the old interfaces and I think most of
> them will stay like that. The config options BUFFER_HEAD and FS_IOMAP
> make the distinction what people care about most. In case of ntfs it's
> clearly for interoperability.
>
> As a user I'd be interested in feature parity with ntfs3, eg. I don't
> see the label ioctls supported but it's a minor thing.
I can confirm that achieving full feature parity with ntfs3, including
the label ioctl support, in the next version.
Thanks for your feedback!


> Ideally there's
> one full featured implementation but I take it that it may not be
> feasible to update ntfs3 so it's equivalent to ntfs+. As this is not a
> native linux filesystem swapping the implementation can be fairly
> transparent, depending only on the config options. The drawback is
> losing the history of fixed bugs that may show up again.
>
> We could do the same as when ntfs3 appeared, but back then it had
> arguably better position as it brought full write support. Right now I
> understand it more of as maintenance problem.

On Mon, Oct 20, 2025 at 11:07:38AM +0900, Namjae Jeon wrote:
> Introduction
> ============

Can you write the documentation at least in
Documentation/filesystems/ntfsplus.rst?

 
> - Journaling support:
>    ntfs3 does not provide full journaling support. It only implement journal
>    replay[4], which in our testing did not function correctly. My next task
>    after upstreaming will be to add full journal support to ntfsplus.

What's the plan for journaling? Mirroring the Windows implementation AFAIK?

For the timeline: I guess you plan to submit journaling patches right after
ntfsplus is merged (at least applied to the filesystem tree or direct PR to
Linus), or would it be done for the subsequent release cycle (6.n+1)?

Regarding stability: As it is a new filesystem, shouldn't it be marked
experimental (and be stabilized for a few cycles) first?

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

On Tue, Oct 21, 2025 at 9:17 AM Bagas Sanjaya <bagasdotme@gmail.com> wrote:
>
> On Mon, Oct 20, 2025 at 11:07:38AM +0900, Namjae Jeon wrote:
> > Introduction
> > ============
>
> Can you write the documentation at least in
> Documentation/filesystems/ntfsplus.rst?
Okay, I will add it on the next version.
>
>
> > - Journaling support:
> >    ntfs3 does not provide full journaling support. It only implement journal
> >    replay[4], which in our testing did not function correctly. My next task
> >    after upstreaming will be to add full journal support to ntfsplus.
>
> What's the plan for journaling? Mirroring the Windows implementation AFAIK?
Yes. It would be best to first obtain the NTFS journal specification,
and I'll try that.
>
> For the timeline: I guess you plan to submit journaling patches right after
> ntfsplus is merged (at least applied to the filesystem tree or direct PR to
> Linus), or would it be done for the subsequent release cycle (6.n+1)?
It will probably take about a year to implement and stabilize it.

>
> Regarding stability: As it is a new filesystem, shouldn't it be marked
> experimental (and be stabilized for a few cycles) first?
I heard from Chrisitan's email that he was considering adding fs/staging trees.
In my opinion, it would be a good idea to promote ntfsplus after it's
been tested
there for a few cycles. And an experimental mark is also possible.
>
> Thanks.
Thanks!
>
> --
> An old man doll... just what I always wanted! - Clara

On Tue, Oct 21, 2025 at 10:55:15AM +0900, Namjae Jeon wrote:
> On Tue, Oct 21, 2025 at 9:17 AM Bagas Sanjaya <bagasdotme@gmail.com> wrote:
> >
> > On Mon, Oct 20, 2025 at 11:07:38AM +0900, Namjae Jeon wrote:
> > > Introduction
> > > ============
> >
> > Can you write the documentation at least in
> > Documentation/filesystems/ntfsplus.rst?
> Okay, I will add it on the next version.
> >
> >
> > > - Journaling support:
> > >    ntfs3 does not provide full journaling support. It only implement journal
> > >    replay[4], which in our testing did not function correctly. My next task
> > >    after upstreaming will be to add full journal support to ntfsplus.
> >
> > What's the plan for journaling? Mirroring the Windows implementation AFAIK?
> Yes. It would be best to first obtain the NTFS journal specification,
> and I'll try that.
> >
> > For the timeline: I guess you plan to submit journaling patches right after
> > ntfsplus is merged (at least applied to the filesystem tree or direct PR to
> > Linus), or would it be done for the subsequent release cycle (6.n+1)?
> It will probably take about a year to implement and stabilize it.

I didn't understand. You mean ntfsplus will be non-journaling fs for a while
after upstreaming, right?

> 
> >
> > Regarding stability: As it is a new filesystem, shouldn't it be marked
> > experimental (and be stabilized for a few cycles) first?
> I heard from Chrisitan's email that he was considering adding fs/staging trees.
> In my opinion, it would be a good idea to promote ntfsplus after it's
> been tested
> there for a few cycles. And an experimental mark is also possible.

Ack.

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

Hello,

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.

Is this new driver going to replace existing ntfs3 driver? Or should it
live side-by-side together with ntfs3?

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

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..)?

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.

Pali

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.
>
> 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:)

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

On Wed, Oct 22, 2025 at 7:19 AM Pali Rohár <pali@kernel.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@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.
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:)

On Wednesday 22 October 2025 11:13:50 Namjae Jeon wrote:
> On Wed, Oct 22, 2025 at 7:19 AM Pali Rohár <pali@kernel.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@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.
> 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:)

On Thu, Oct 23, 2025 at 3:52 AM Pali Rohár <pali@kernel.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@kernel.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@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.
> > 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:)