The exFAT filesystem is coming to Linux — Paragon software’s not happy about it, Ars Technica

/ Proprietary filesystem vendor Paragon Software seems to feel threatened by the pending. inclusion of a Microsoft-sanctioned exFAT in the Linux 5.7 kernel. When software and operating system giant Microsoft announced its support for inclusion of the exFAT filesystem directly into the Linux kernel back in August, it did not get a ton of press coverage. But filesystem vendor Paragon Software clearly noticed this month’s merge of the Microsoft-approved, largely Samsung-authored version of exFAT into the VFS for-next repository , which will in turn merge into Linux 5.7 — and Paragon doesn’t seem happy about it.

Yesterday, Paragon issued a press release about European gateway-modem vendor Sagemcom adopting its version of exFAT into an upcoming series of Linux- based routers. Unfortunately, it chose to preface the announcement with a stream of FUD (Fear, Uncertainty, and Doubt) that wouldn’t have looked out of place on Steve Ballmer’s letterhead in the (s.) Breaking down the FUD

Paragon described its arguments against open source software — which appeared directly in my inbox — as an “article (available for publication in any form) explaining why the open source model did work in 3 cases. “

All three of Paragon’s offered cases were curious examples, at best.

Case one: Android Let’s first look into some cases where filesystems similar to exFAT were supported in Unix derivatives and how that worked from an open source perspective.

The most sound case is Android, which creates a native Linux ext4FS container to run apps from FAT formatted flash cards ( 3 . This shows the inability (or unwillingness based on the realistic estimation of a needed effort) of software giant Google to make its own implementation of a much simpler FAT in the Android Kernel.

The footnote leads the reader to a lengthy XDA-developers article that explains the long history of SD card filesystems in the Android operating system . An extremely brief summation: originally, Android used the largely compatible (VFAT) (implementation of the Windows FAT) filesystem. This caused several issues — including security problems due to a lack of multi-user security metadata.

These problems led Google to replace VFAT with a largely Samsung-developed FUSE (Filesystem in Userspace) implementation of exFAT. This solved the security issues twice over — not only were ACLs now supported, the FUSE filesystem could even be mounted for individual users. Unfortunately, this led to performance issues — as convenient as FUSE might be, userspace filesystems don’t perform as well as in-kernel filesystems.

Still with us so far? Great. The final step in this particular story is Google replacing exFAT-FUSE with SDCardFS, another Samsung-developed project that — confusingly — isn’t really a filesystem at all. Instead, it’s an in-kernel wrapper that passes API calls to a lower-level filesystem. SDCardFS replaces FUSE, not the filesystem, and thus allows emulated filesystems to run in kernel space.

If you’re wondering where proprietary software comes in to save the day, the answer is simple: it does not. This is a story of the largest smartphone operating system in the world consistently and successfully using open source software, improving performance and security along the way.

What’s not yet clear is whether Google specifically will use the new in-kernel exFAT landing in 5.7 in Android or will continue to use Samsung’s SDCardFS filesystem wrapper. SDCardFS solved Android’s auxiliary-storage performance problems, and it may provide additional security benefits that simply using an in-kernel exFAT would not.

Case two: MacOS The other case is Mac OS — another Unix derivative that still does not have commercial support for NTFS-write mode — it only supports NTFS in a read-only mode. That appears strange given the existence of NTFS-3G for Linux. One can activate write support — but there’s no guarantee that NTFS volumes won’t be corrupted during write operations.

There are several problems with using MacOS ‘iffy NTFS support as a case against open source software. The first is that NTFS support doesn’t seem to be a real priority for Apple in the first place. MacOS Classic had no NTFS support at all. The NTFS support present after Mac OS X 3) “Panther” was, effectively, a freebie — it was already there in the FreeBSD-derived VFS (Virtual File System) and network stack.

Another problem with this comparison is that NTFS is a full-featured, fully modern filesystem with no missing parts. By contrast, exFAT — the filesystem whose Linux kernel implementation Paragon is throwing FUD at — is an extremely bare-bones, lightweight filesystem designed for use in embedded devices.

The final nail in this particular coffin is that the open source NTFS implementation used by MacOS isn’t Microsoft-sanctioned. It’s a clean-room reverse-engineered workaround of a proprietary filesystem. Worse, it’s an implementation made at a time when Microsoft actively wanted to close the open source community out — and it’s not even the modern version.

As Paragon notes, NTFS-3G is the modern open source implementation of NTFS. NTFS-3G, which is dual-licensed proprietary / GPL, does not suffer from potential write-corruption issues — and it’s available on MacOS, as well as on Linux.

Mac users who don’t need the highest performance can install a FUSE implementation of NTFS-3G for free using (Homebrew) , while those desiring native or near-native performance can purchase a lifetime license directly from Tuxera. Each $ 25 license includes perpetual free upgrades and installation on up to three personal computers.

It’s probably worth noting that Paragon — in addition to selling a proprietary implementation of exFAT — sells a proprietary implementation of NTFS for the Mac .

Case three: SMB An additional example, away from filesystems, is an open source SMB protocol implementation. Mac OS, as well as the majority of printer manufacturers, do not rely on an open-source solution, as there are several commercial implementations of SMB as soon as a commercial level of support is required.

It’s unclear why Paragon believed this to be a good argument against open source implementations of a file system. SMB (Server Message Block) isn’t a filesystem at all; It’s a network communication protocol introduced with Microsoft Windows.

It’s certainly true that many proprietary implementations of SMB exist – (including one in direct) partnership with Microsoft, made by Paragon rival and NTFS-3G vendor Tuxera. But this is another very odd flex to try to make against open source filesystem implementations.

Leaving aside the question of what SMB has to do with exFAT, we should note the extensive commercial use of Samba , the original gangster of open source SMB networking. In particular, (Synology uses Samba for its NAS (Network Attached Storage) servers, as do Netgear and QNAP . Samba.org itself also lists high-profile commercial vendors including but not limited to American Megatrends, Hewlett-Packard, Veritas, and VMWare.

Open source is here to stay

We congratulate Paragon on closing their timely exFAT deal with Sagemcom. Although there’s good reason to believe that the Samsung-derived and Microsoft-approved exFAT implementation in Linux 5.7 will be secure, stable, and highly performant, it’s not here yet — and it isn’t even in the next upcoming Linux kernel, 5.6, which we expect to hit general availability in late April or early May.

In the meantime, a company with a business need to finalize design decisions — like Sagemcom — probably is making the right decision to use a proprietary exFAT implementation, with commercial support. The license costs are probably a small percentage of what the company stands to earn in gross router sales, and Paragon’s implementation is a known value.

However, we suspect the exFAT landscape will tilt significantly once Samsung’s Microsoft-blessed version hits the mainstream Linux kernel. Hopefully, Paragon will evolve a more modern open source strategy now, while it still has time.

                                                     (Read More)