ReactOS is using btrfs, which has so many useful options that FAT will never see (zstd, xxhash, flash-aware options, snapshots, send/receive, etc.). This is positioned both for Linux and Windows.
Microsoft itself restrains ReFS to enterprise use, and btrfs offers so much more functionality. We should stop using a file system from the '80s.
Btrfs has a lot of bugs while being active for a long time. This is mostly related to its complexity.
If I'm going to implement a filesystem for a custom hardware I would definitely not chose btrfs.
By all means, choose the Microsoft solution, because patent licensing is good for everyone.
And the bug myth past into history years ago.
"So, we'll repeat this once more: as a single-disk filesystem, btrfs has been stable and for the most part performant for years."
https://arstechnica.com/gadgets/2021/09/examining-btrfs-linu...
We are all forced to pay for this ancient software every time we buy a device that uses it.
Wouldn't this money be better used elsewhere?
https://en.m.wikipedia.org/wiki/File_Allocation_Table#Patent...
x86_64 with SSE2 is also patent-free right now, as an example.
FAT is still popular because it is very easy to implement, and anything can read and write to it. It is pretty easy to implement the file system on a low power microcontroller and have it write data to an SD card. Your users can then plug that SD card into any computer and view the data, or add to it.
Using btrfs in a situation like this means a lot more coding on your end, and your users lose the convenience of the SD card using a file system they can easily interact with.
Nobody is using FAT for their primary system partition. It is almost exclusively relegated to embedded systems and small external storage devices where broad compatibility is an important feature.
Or the sheer ubiquity, and therefore cross-device compatibility.
Still, something similar to fuse might help with the licensing.
The shared set there is basically just fat and exfat.
If Microsoft and Apple collaborated on a new filesystem, or even just supported it, then we might have a possible successor. However even with that, the millions of already shipped devices won't support it. This during the transition period of many years there will still need to be support for fat.
That keeps fat the lowest common denominator and everything supporting it.
The only way to get a universal standard is to have the community do it and have enough people use it that the big companies have to capitulate.
But as you pointed out, in a transitionary period there is still a need to support older devices and software. FOSS purists may also not approve of using exFAT in some situations, since the relevant patents have not yet expired, even if MS has released them to the OIN.
2. Switching to BTRFS would be a breaking change. BigFAT wouldn't be. You can still use the card in devices that do not support it, without needing to reformat. Those devices would just lose access to some files.
Do you know what happens when you insert a btrfs-formatted SD card or USB stick into a Windows or macOS machine? It tells you that the drive is unreadable and asks if you want to initialize it. If the user answers yes to that question, the system formats the drive and all of their data is lost.
With a BigFAT-formatted drive, the system will mount it no problem, the user will be able to browse the contents, and the only weird part is that their largest files are split into parts.
3rd parties can write drivers for Windows, you know. A small, read-only FAT partition on a USB stick or SD card could contain the installable drivers necessary to read/write the rest of the disk.
However, that's unnecessary. The best option for a universal file system is UDF. Windows, Mac, and Linux all have full read/write support.
Anything involving embedded and without deep pockets has no other option, FAT (sadly) still is the least common denominator. Some speak ExFAT, but not sure how good the tooling support is outside of Microsoft, and there are still patent concerns.
e.g. some widget without network connection that optionally logs an audit trail to an attached USB media, could still end up with only a couple hundred kilobytes of soldered-on ROM to store the whole firmware, while wanting to write more than 4GB of audit logs.
I just want to transfer files on USB sticks without worrying about file size or the OS accessing it. The infuriating part is that it is 2022 and if you want to reliably and easily move files larger than 3-4GB on removable media people tell you to use proprietary MS file systems like ExFAT And NTFS. That is unacceptable.
We NEED a simple, portable, and freely open file system spec for removable media that handles large drives and files.
I would note that one way to work around the cost-incentives of IoT manufacturers, would be to encourage them to externalize the storage-layer costs from the device's BOM, by focusing on getting "object-storage oriented" NAND flash controllers pushed down from enterprise to regular retail availability. That way, all the filesystem-layer smarts end up living in the SD card itself — which is sold separately. (It'd be sort of a second coming of the ancient Commodore 1540/1541 paradigm, where the disk controller presented not as block storage, but as, essentially, a single-user serial-attached NAS.)
On the other hand, NTFS on Windows, Ext* on Linux, or ZFS on any supported OS, has not been known to eat data as frequently.
According to them (https://btrfs.wiki.kernel.org/index.php/Status) only RAID56 is unstable.
I've had a hunt for the specific instructions but I'm afraid I can't find it again with a search. The gist of it was to:
- create Btrfs mirror using two qemu virtual disks
- pull the (virtual) plug on one of the pair to disconnect it, then later reconnect it
- Btrfs ends up hosing both the outdated and current copies of the mirror, leading to complete dataloss of the entire mirror
[1] https://kb.synology.com/en-global/DSM/tutorial/How_can_I_rec...
"So, we'll repeat this once more: as a single-disk filesystem, btrfs has been stable and for the most part performant for years."
https://arstechnica.com/gadgets/2021/09/examining-btrfs-linu...