lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOQ4uxgSJXrQ5YEzEZrP5yFobzcHBShwSUX9DvHsmex0w-d5uQ@mail.gmail.com>
Date: Mon, 29 Dec 2025 15:34:09 +0100
From: Amir Goldstein <amir73il@...il.com>
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, 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 2:45 PM 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
> ===================================   ========   ===========

For completion of this report, are the 287 passed xfstests a super set
of the 218
passed xfstest for ntfs3?
IOW, are there any known functional regressions from ntfs3 to ntfs?

Thanks,
Amir.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ