Linux now has a second modern, in-kernel, read‑write implementation for NTFS — and it’s not a drop‑in tweak to the Paragon code everyone has been using: it’s a ground‑up rework called
ntfsplus, submitted as an 11‑patch series by kernel filesystem engineer Namjae Jeon.
Background / Overview
NTFS has long been the lingua franca between Windows and other operating systems. For years Linux relied on userland FUSE implementations — most notably
ntfs-3g — or a limited read‑only in‑kernel driver. In November 2021 the kernel accepted a donated GPL driver,
ntfs3, backed by Paragon Software; that driver brought read‑write capabilities into the kernel but has been controversial because of maintenance and robustness concerns. Into that landscape comes ntfsplus: a rework built not on top of Paragon’s ntfs3 but on the older
classic read‑only kernel NTFS codebase, modernized to use current kernel IO infrastructure, and extended to support writes, a userspace fsck utility, and other features expected of an in‑kernel filesystem. The author argues that the classic code is clearer and easier to maintain as a foundation for a full read‑write stack, and delivers concrete performance and compatibility goals. I reviewed the upstream patch series and early press coverage, and also scanned community forum archives and discussion threads about NTFS drivers to gauge initial reaction and deployment risk.
Why another NTFS driver?
Linux already has three practical options for NTFS access:
- ntfs-3g — FUSE userspace driver, mature and widely deployed; safe but comes with FUSE's performance and privilege model limitations.
- ntfs3 — in‑kernel driver donated by Paragon and merged in Linux 5.15 (November 2021); provides in‑kernel read‑write NTFS but has drawn criticism for maintenance and some missing features.
- legacy kernel ntfs — older read‑only driver that used buffer_heads and kernel page APIs.
The ntfsplus project posits that combining the clarity of the classic driver with modern kernel mechanisms produces a better maintainable and higher‑performing implementation than ntfs3. That’s the rationale behind the new work: bring back the clean structure of the old driver, but modernize IO paths to
iomap and
folio mappings, remove buffer_head dependencies, and add utilities so NTFS can be managed and repaired in the same way Linux filesystems are.
Key design goals in ntfsplus
- Implement write support cleanly on the classic NTFS code, including delayed allocation to reduce fragmentation and improve multi‑threaded write throughput.
- Replace buffer_heads with iomap for mapping file extents and buffer management, aligning with modern kernel IO architecture.
- Move from page‑based operations to folio support, allowing larger contiguous units to be managed more efficiently.
- Introduce a public userspace utility suite — ntfsprogs‑plus — including fsck.ntfs so NTFS can be tested against xfstests and repaired from userspace.
- Plan to fully implement NTFS journaling (the driver currently does not have full journal support).
Technical deep dive: what changed and why it matters
From buffer_heads to iomap
Older kernel filesystem code often used buffer_heads to represent block‑level buffers; that model has been steadily superseded by iomap, which provides a unified, modernized interface for buffered IO, direct IO, and file extent mapping. By choosing iomap,
ntfsplus aligns with how contemporary filesystems interact with the block layer and the pagecache, simplifies IO paths, and reduces maintenance surface area when the kernel changes the underlying IO primitives. This modern interface is central to predictable performance and easier review by other kernel maintainers.
Folios, not pages
A folio is essentially a grouped set of pages that lets the kernel treat large contiguous regions as a single unit. Enabling
large folios can yield substantial performance wins for sequential IO patterns because the kernel can work with larger chunks and avoid repeated metadata and locking overhead. The ext4 subtree showed measurable benefits when it enabled large folios in Linux 6.16 — workloads saw double‑digit percentage gains in various benchmarks — and ntfsplus is adopting that same technique to capture similar wins for NTFS IO paths.
Delayed allocation and multi‑cluster allocation
On Linux filesystems, delayed allocation (delalloc) lets the filesystem postpone physical block assignment until writeback, enabling better cluster packing and fewer metadata updates. ntfsplus implements delalloc and
multi‑cluster allocation to reduce fragmentation on NTFS volumes and to improve multithreaded write throughput — a behavior that can be particularly noticeable when copying many files in parallel or when VMs and containers generate concurrent writes. The author’s benchmarks claim large improvements in multi‑threaded write scenarios versus ntfs3.
Userspace utilities and fsck.ntfs
A longstanding gap for in‑kernel NTFS drivers has been the lack of integral filesystem utilities. ntfs‑3g historically brought its own ntfsprogs userspace suite; ntfs3 did not provide a corresponding fsck or public toolset. ntfsplus explicitly creates
ntfsprogs‑plus, aimed at providing an fsck implementation and other utilities so distributions can test NTFS with xfstests and repair inconsistent volumes in the way they would ext4 or XFS. That’s a significant step toward operational parity with other filesystems on Linux.
Performance: what the numbers say
Namjae Jeon’s patch series ships with iozone bench numbers showing modest single‑thread write improvements (roughly
3–5%) and much larger multi‑threaded write gains (
~35–110%) compared with ntfs3, while read throughput remained similar between the two drivers. The specific tables in the patch show a dramatic delta in parallel workloads where folio and delalloc optimizations can be leveraged. These results are echoed by independent early analysis in the Linux media, which highlighted ntfsplus’ multi‑threaded write advantage. That said, microbenchmarks are only part of the picture. Filesystem performance depends heavily on workload character: small random writes, metadata‑heavy workloads, and mixed read/write patterns can expose different bottlenecks. The large folio optimizations that help sequential writes can sometimes require tuning for workloads that suffer from memory oversubscription or very small IO sizes. ext4’s folio enablement required follow‑up fixes to cap folio orders on some configurations — an example of how enabling large folios needs careful upstream review and testing.
Correctness, journaling, and risk
Performance wins are good news, but the most critical filesystem property is correctness — data integrity in the face of crashes, power loss, and concurrent access.
- ntfsplus currently does not implement full NTFS journaling; it implements journal replay (the logic to recover a journaled volume after an unclean unmount), and even that replay path needed further work per the author’s own notes. Paragon’s ntfs3 likewise offers journal replay only, which means journaling parity with Windows (and with Windows’ expectations of the NTFS journal) is not fully solved in the kernel ecosystem yet. The ntfsplus author explicitly lists full journaling implementation as the next major task and estimates substantial time to reach parity.
- The kernel community’s filesystem maintainers will review ntfsplus not just for performance but for correctness proofs, test coverage, and consistency with the on‑disk format. Filesystem regressions are costly: a single corruption scenario in the wild can create major trust issues and slow adoption. The inclusion of a userspace fsck and xfstests coverage is therefore an essential part of making ntfsplus trustworthy, and the patch series makes that explicit.
- New implementations bring integration costs. Distributions and OEMs will need to decide whether to ship ntfsplus, stick with ntfs3/ntfs‑3g, or offer both. That decision hinges on stability testing, CVE exposure, and cornercase correctness validation on NTFS features Windows uses (reparse points, compression, encryption, alternate data streams, sparse files, etc.. Early coverage notes that ntfsplus aims to support a wide set of features, but until full journaling and extensive cross‑platform interop tests are done, conservative users and enterprise deployments will likely wait.
Upstream prospects and maintenance model
Upstream acceptance into the kernel tree is never automatic. A few practical points determine whether ntfsplus will replace or coexist with ntfs3:
- Code review and maintainability. Namjae Jeon is a respected kernel filesystem developer with prior success (notably the exFAT userspace utilities and kernel exFAT work). That pedigree helps; reviewers still demand clean, well‑documented code with minimal technical debt.
- Test coverage and regressions. The patch author included xfstests harness support and fsck utilities — that’s the kind of evidence maintainers look for to judge long‑term maintenance burden. The kernel’s filesystem maintainers will also look for a stable upstream maintainer and a path for ongoing fixes.
- Community politics and existing codebase. Donating code is rarely the end of the story; it’s the start of a long review and shepherding process. ntfs3, donated by Paragon in 2021, has had questions around long‑term maintenance. ntfsplus’ patches include pointed comparisons to ntfs3; that can be constructive, but it will also invite careful scrutiny from maintainers who will want to verify those criticisms.
- Backward compatibility and dual‑stack options. Kernel distributors may initially ship both drivers, letting admins choose via module selection or fstab options. That’s a pragmatic approach while ntfsplus stabilizes.
What this means for users and admins
- Everyday desktop users: For now, nothing changes immediately. Most desktop distributions will keep existing NTFS options in place while ntfsplus goes through review and validation. Users who depend on stable cross‑platform behavior (external drives, dual‑boot shared volumes) should be cautious before switching drivers on production data.
- Power users and testers: Enthusiasts and testers can build and experiment with the ntfsplus module to evaluate performance and run fsck on test volumes. The availability of xfstests support and a public fsck tool is a positive sign for testability. Run read‑only comparisons first and validate recovery scenarios (unclean unmount, power cycle, etc. before trusting live data.
- Enterprise and OEMs: Large deployments will wait for full journaling support, a stable maintenance model, and a proven track record in the wild. Until then, ntfsplus is promising but not yet a drop‑in replacement for mission‑critical environments.
Strengths, weaknesses, and open questions
Strengths
- Modern architecture: Moving to iomap and folios aligns NTFS with current kernel IO infrastructure, easing maintenance and enabling modern optimizations.
- Performance gains: Significant multi‑threaded write improvements in early benchmarks are compelling for workloads that copy or generate parallel writes.
- Utilities and testability: Including a public fsck and xfstests integration increases the odds of upstream acceptance and practical operational testing.
Weaknesses / Risks
- Incomplete journaling: Without full journal support, some crash recovery semantics could differ from Windows’ expectations, creating potential interoperability risk.
- Upstream burden: Kernel maintainers will judge whether the project reduces the ecosystem’s maintenance burden or multiplies it with yet another driver. The developer’s commitment to long‑term upkeep will be scrutinized.
- Corner cases and hidden incompatibilities: NTFS exposes many Windows‑specific features (compression formats, reparse points, alternate streams, proprietary encryption schemes). Comprehensive validation will be time consuming.
Open questions
- How will ntfsplus handle Windows‑specific NTFS features such as per‑file compression formats and advanced reparse points at production scale?
- What is the realistic timeline for full journaling compatibility with Windows semantics?
- Will distributions default to ntfsplus when both drivers are available — and if so, after what confidence threshold?
Upstream commentary already shows awareness of those questions and a realistic plan from the author to phase in journaling after merging the basic write stack.
Practical advice for adoption
- For testing: build the ntfsplus patch series out of tree and validate on non‑critical volumes first. Use controlled crash/recovery tests and compare behavior against ntfs3 and ntfs‑3g.
- For integration: distributions should treat ntfsplus like any other new filesystem — enable it in a testing channel, run automated xfstests and real‑world workloads, and monitor for regressions.
- For end users: continue using the driver that your distro ships by default for production data; explore ntfsplus only for benchmarking or migration planning.
- For maintainers: encourage upstream code reviews, request more tests for journaling paths, and pressure‑test compatibility with Windows‑created volumes that use advanced NTFS features.
Conclusion
ntfsplus is a thoughtful, modern attempt to give Linux a cleaner, higher‑performance, in‑kernel NTFS implementation that is easier to maintain and test. It’s authored by a respected filesystem developer and deliberately adopts modern kernel mechanisms —
iomap,
folios, and delalloc — that have delivered measurable benefits elsewhere in the kernel. Early benchmarks and the inclusion of userspace utilities make ntfsplus a credible candidate to coexist with or eventually supplant other in‑kernel NTFS options. That said, the filesystem world rewards patience. The most important milestone is correctness under failure — full journaling and broad interoperability tests must precede widespread deployment. Until then, distributions, OEMs, and administrators will weigh the performance upside against the need for rock‑solid data integrity and long‑term maintenance commitments. The patch series is a major step forward; the hard work — review, testing, and field hardening — is just beginning.
Source: theregister.com
NTFSplus is a new read-write NTFS driver for Linux