Last March, proprietary file system vendor Paragon Software unleashed a flurry of anti-open source FUD over a Samsung-derived exFAT implementation that made its way into the Linux kernel. A few months later, Paragon seemed to realize its mistake and began the painstaking process of getting its own implementation of Microsoft’s NTFS (the default file system for all Windows machines) into the kernel as well.
While Paragon is still clearly struggling to align its processes and practices to be open source-friendly, Linux kernel BDFL Linus Torvalds appears to be personally interested in the process. After nearly a year of effort by Paragon, Torvalds continues to gently nudge both the company and skeptical Linux developers to move the project forward.
For those familiar with day-to-day Linux usage, the usefulness of Paragon’s version of NTFS may not be immediately apparent. The Linux kernel already has one implementation of NTFS, and most distributions make it incredibly easy to install and use another FUSE-based implementation (ntfs-3g).
However, both existing implementations have problems. The in-kernel implementation of NTFS is extremely old, poorly maintained, and should only be used as read-only. As a result, most people who actually need to mount NTFS filesystems on Linux use the ntfs-3g driver instead.
NTFS-3G is in pretty good shape – it’s much newer than the in-kernel NTFS implementation, and as Linux file system guru Ted Ts’o points out, it passes even more automated file system tests than Paragon’s own NTFS3.
Unfortunately, the performance of ntfs-3g is terrible due to working in user space instead of kernel. In Ts’o’s tests, Paragon’s ntfs3 completed the automated tests in 8,106 seconds, but the FUSE-based ntfs-3g took a whopping 34,783 seconds.
Bugs and performance aside, ongoing maintenance is an important aspect of Paragon’s ntfs3 to make it in-kernel. Torvalds opined that “Paragon should just file a pull request for [ntfs3]- but he did this after noting that the code should get OK from the current maintainers and that Paragon itself should maintain the code in the future. (Paragon developer Konstantin Komarov quickly replied that the company intended to to continue to be maintained once accepted.)
Why not Paragon?
While Torvalds himself seems positive about Paragon’s ntfs3 driver mainstreaming, as do several other users and developers, there are still some concerns about properly integrating Paragon and its workflow into the kernel developer community and according to those standards. community.
Ted Ts’o – main maintainer of Linux’s ext3/ext4 filesystems, and the e2fsprogs userspace utilities used to manage them – seems to be the most critical. In addition to the slightly higher number of failed automated tests he found in Paragon’s code, he notes other issues, such as system-wide deadlocks that crop up when ntfs3 is overworked. (This is a problem we’ve also heard from people who’ve bought Paragon’s ntfs3 over the years.)
Ts’o also raises questions about maintenance and communications, saying, “I’d feel better if *someone* at Paragon Software responded to Darrick [Wong] and my questions about their quality assurance, and/or made commitments that they at least *try* to fix the issues that trivially cropped up after about 5 minutes of testing using fstests.”
Fellow developer Darrick Wong added that he wants to make sure Paragon is invested in maintenance going forward so that ntfs3 doesn’t become “one of the shabby Linux file system drivers like [the current in-kernel ntfs].”
The path forward
Despite Ts’o and Wong’s skepticism, we generally expect the inclusion of Paragon’s ntfs3 to happen eventually. The company has worked for a year so far to turn its 27,000 lines of code thrown over the wall into a Linux-ready patchset — and while primary developer Komarov may not have always responded as quickly or thoroughly as Ts’o and Wong prefer , he continues to respond.
For his part, Torvalds seems determined to now find a performant, modern, maintainable replacement for the old (2001 era) and rarely used ntfs implementation in the kernel. As long as Paragon remains willing to keep playing, it seems likely it will eventually get there – perhaps even in time for the 5.15 kernel.