| 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
| ||
|
Message-ID: <CAKYAXd-7voNQqfrLm=Jakee0YWMyZsyOwBrah=RfwCxjHpn1pw@mail.gmail.com> Date: Wed, 31 Dec 2025 08:40:55 +0900 From: Namjae Jeon <linkinjeon@...nel.org> To: Neal Gompa <neal@...pa.dev> 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 Tue, Dec 30, 2025 at 6:14 AM Neal Gompa <neal@...pa.dev> wrote: > > 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? some people asked the same question, I said I would start that work as soon as this upstream is finished. > I vaguely recall that a similar promise was made with ntfs3 and, > well... here we are. I expected it would end up like this after all. But this time, it will be different. In a similar case, when I upstreamed exfat filesystem, Eric requested public utilities. After upstreaming exfat, we developed and released exfatprogs, which included mkfs, fsck, dump, etc, and currently, well-known CE vendors have adopted linux exfat driver and exfatprogs for their products. I will maintain the new ntfs in the same way. > > 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