Message-ID: <CAEg-Je9nZbN8LkjX2n9MqobXBv91NYZk5v08u1ptufn=hSXnCg@mail.gmail.com>
Date: Mon, 29 Dec 2025 14:35:57 -0500
From: Neal Gompa <neal@...pa.dev>
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, pali@...nel.org, 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 v3 00/12] ntfs filesystem remake

On Mon, Dec 29, 2025 at 7:47 AM Namjae Jeon <linkinjeon@...nel.org> wrote:
>
> 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.
>
> The remade ntfs 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
> new ntfs 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:
>
>    - ntfs vs. ntfs3:
>
>      * Performance was benchmarked using iozone with various chunk size.
>         - In single-thread(1T) write tests, ntfs show approximately
>           3~5% better performance.
>         - In multi-thread(4T) write tests, ntfs show approximately
>           35~110% better performance.
>         - Read throughput is identical for both ntfs implementations.
>
>      1GB file      size:4096           size:16384           size:65536
>      MB/sec       ntfs | ntfs3        ntfs | ntfs3        ntfs | 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          ntfs | ntfs3        ntfs | ntfs3        ntfs | 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          ntfs | ntfs3        ntfs | ntfs3        ntfs | ntfs3
>      ─────────────────────────────────────────────────────────────────
>      mount        0.38 | 2.03         0.39 | 2.25         0.70 | 4.51
>
>    The following are the reasons why ntfs 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:
>       ntfs passed 287 tests, significantly higher than ntfs3's 218.
>       ntfs 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.
>       ntfs 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 ntfs.
>
>
> The feature comparison summary
> ==============================
>
> Feature                               ntfs       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
>
>
> Available in the Git repository at:
> ===================================
> git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/ntfs.git ntfs-next
>

Thanks for renaming this to ntfs. :)

That said, are you able to make a commitment about journaling support
work? I vaguely recall that a similar promise was made with ntfs3 and,
well... here we are.

I would have preferred to see it as part of the initial upstreaming,
but I'm equally fine with some kind of known timeline post merge for
working on it.

Thanks for this great work!


-- 
真実はいつも一つ！/ Always, there's only one truth!

Powered by blists - more mailing lists