ExFAT is a file system optimized for flash drives, meaning storage devices without moving parts where seek times are constant. It sounds like you're using it for a mechanical hard drive – which is what's causing the poor performance that you're experiencing. You should reformat the drive to HFS+ or FAT32 and only use exFAT for solid-state drives. It has system firmware 3.0.2 on it and presumably no exfat support. I've not received my SX Pro yet but want to get the console ready for when it arrives. Can anyone confirm 100% that SX OS is working on 5.0.2? I know Executer have said it is, but it would just be reassuring to hear from some others.
TL;DR version
For Mac OS X to read-write exFAT formatted HDD, two options
- Format using Mac:
- Disk Utility ->
- Erase ->
- choose exFAT ->
- OK
- Format using Windows:
- My Computer ->
- Right Click HDD ->
- Format ->
- choose exFAT ->
- AUS 128 kilobytes->
- Start
Background
Turns out exFAT exists so that Mac and Windows can co-exist harmoniously. There are many forum discussions and how-toarticlesoutthererecommending exFAT if you want to share files between Mac and Windows.
What most of them failed to mention is the correct allocation unit size / cluster size necessary for the harmonious relationship to work. Most of them talked about what the allocation unit size does, which might be misleading for the purpose of getting it up and running seamlessly.
My Story
I want to use an external HDD as the scratch disk for a video editing project on a Mac OS X 10.7.5. But my files are on my Windows 8.1 laptop HDD, which was formatted in NTFS. By default, Mac OS X can only read but not write to NTFS HDD. Of course there are NTFS read-write solutions out there for Mac. Among them Tuxera NTFS, Paragon NTFS, or NTFS-3G FUSE.
Disclaimer: I have not tried Tuxera or Paragon. I used NTFS-3G FUSE from 2009-2013 on my Macbook Snow Leopard, so far so good. I have not tried it on later versions of Mac OS X. There is a high chance of it not working on OS X 10.7 and later (see Known Issues).
Then I found out that if I format the HDD in exFAT, it should work for both Windows and OS X. I figured that since most of my files are videos with BIG file sizes, I chose 4096 kilobytes for the AUS. It formatted nicely. But lo and behold, OS X doesn't even recognize the HDD. I tried to force mount it but nope, it doesn't work.
So I figured that if I use OS X's Disk Utility to format, it should work for both Mac and Windows. This time it works! Turns out Disk Utility formatted the HDD with 128 kilobytes AUS (131072 bytes divide by 1024).
Just for kicks, I used Windows to format it again with AUS 128 kilobytes. Yeap, it works.
Conclusion
128 kilobytes is the harmonious constant between Windows and Mac OS X 10.7.5. Use 128 kilobytes AUS while formatting a HDD so that it works for both Windows and Mac OS X.
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 didn't 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 1990s.
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 didn't 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 FAT32 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.
AdvertisementStill 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 thereby 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 doesn't. 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 10.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.
AdvertisementAs 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 $15 license includes perpetual free upgrades and installation on up to three personal computers.
Ubuntu 18.04 Exfat Support
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.
Os X Exfat Support Tool
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.
