What's interesting to me is that there doesn't seem to be a modern filesystem that works across all major platforms. btrfs has Linux and this (unofficial) Windows driver; ZFS has Linux and OS X support but nothing for Windows. NTFS is pretty much Windows and Linux only for good write access, and APFS is macOS-only.
I realize that designing a filesystem and writing drivers for it are very difficult tasks, but surely it would be extremely beneficial to have at least 1 open source filesystem that has good support across all platforms?
> surely it would be extremely beneficial to have at least 1 open source filesystem that has good support across all platforms
The comedy of this is that there are actually plenty of FSes common to all three of these OSes, they're just not considered "modern"; FAT32 is still the most commonly used FS for interop, even as it shows its age with poor support for very large files (2+GB) and file systems, but you also have ISO(9660) and (the best answer we currently have) UDF supported by all three OSes natively and openly without patents or other licensing restrictions. The latter two are not commonly used as read/write filesystems, but have zero inherent restrictions on being able to be used in such a way.
However, the problem has been largely supplanted by having a fast and well-functioning network and people moving to "The Cloud" for, well, everything. It's hard to know how much of the Great Cloud Migration is caused by these kinds of intentionally engineered interoperability fails, especially the monumentally stupid exFAT patent... It's interesting to ponder given the people likely to complain the most about filesystems today are people who want to move large files (4+GB) between OSes without anguish, where the network is still just too slow to handle the task well.
ISO 9660 is not at all a general purpose filesystem. Although fairly trivial to reason about and implement, little and big endian systems required entirely separate structures written to disc or files would not be accessible.
Myth 2 was a popular testing media in those days due to Apple and PC endian differences. As I recall Bungie did some clever crafting on the structures to share some of the media between platforms while keeping binaries separated. Even had a fun picture of soulblighter in Finder through icon trickery.
-wrote commercial CD mastering and storage software many many moons ago
However, it is not, not even close to, a decent file system. (And that's before we even get into RRIP and Joliet. /shudder)
And IIRC, ISO9660 has issues with being written - the path table needs to be ordered. Yes, you can make it modifiable on the fly, but the pain to do so is just not worth it.
> UDF supported by all three OSes natively and openly
Wasn't there a major problem in that all the operating systems supported different versions of the UDF standard? And most of them treat it as an optical disk format, so I wouldn't be surprised if some of them acted like it was read-only.
> It's hard to know how much of the Great Cloud Migration is caused by these kinds of intentionally engineered interoperability fails
+1. The great benefit of the "cloud" and the internet in general is as an escape from vertically integrated silos. Which is why all the big players are frantically trying to rebuild some kind of lock-in along different lines.
How well does UDF perform for random-access read-write devices? It was my impression that it is optimized for read-often, write-rarely, possibly without possibility of overwriting.
I believe that part of the issue is that the file systems are tailored to the needs of the operating system they run on. Take file permissions. As the basic permissions model, Linux uses user/group/everyone, while Windows uses ACLs. Linux also supports ACLs but they don't work in the same way that Windows' does. NTFS is built to meet the needs of Windows, while Ext4 is built to meet the needs of Linux. You can use each on the other OS with the right drivers, but just as data drives with very roughly mapped permissions.
Hmm, that's a good point! However I don't think this would be a major hurdle: file permissions offer OS-level security only, not disk-level security/encryption, so it would still make sense for different OS drivers to implement only their specific permissions attributes.
To make your point more clear: NTFS is built for Windows, while every other modern filesystem is made for OS's with Unix-style permissions (including BSDs like OS X).
They are, sort of. Linux (at least) can do multiple ACLs per FS object (U/G/W: rwx) whereas NTFS does have a slightly richer set of possible permissions listed when you use the GUI but they really boil down to the same in practice.
Novell's NWFS and NSS filesystems have always supported trustee assignments that flow recursively at the point of access rather than the point of administration. Unless you have used either of those as an administrator involving say 1000s of people and groups and millions of files then you will not appreciate this distinction.
On both Windows and Linux, if you have to make changes to FS perms, then the ACLs have to be made to each object - file or folder. On NWFS and NSS, you only do it at a point (say a directory) and then it will recurse automatically unless blocked by an IRF (Inheritable Rights Filter - bloody stupid but there if you really need it)
The end result is that making a change to a tree of files on any Unix or Windows FS takes from seconds to hours. On NWFS or NSS it generally takes seconds (for the screen to refresh).
I have never quite understood why Linux or Windows admins (I'm both) have put up with the rubbish ACLs and implementations of "modern" filesystems. Oooh RAID in software and snapshots - oh how nice.
The POSIX ACLs thing is genuinely shit, very outdated and absolute rubbish. This is the 21st century FFS. Why on earth should you wait as each file in a collection that you have deemed as belonging to sales but be readable by fred be stamped as such? Why should users be able to see the path down to a point where they have access? Why on earth should 21st C admins have to watch a change of security requirements take from a few seconds to hours/days?
>On both Windows and Linux, if you have to make changes to FS perms, then the ACLs have to be made to each object - file or folder. On NWFS and NSS, you only do it at a point (say a directory) and then it will recurse automatically unless blocked by an IRF (Inheritable Rights Filter
NTFS has perms inheritance (and overriding) since forever, did you know that?
>The end result is that making a change to a tree of files on any Unix or Windows FS takes from seconds to hours. On NWFS or NSS it generally takes seconds (for the screen to refresh).
Painless administration requires careful planning, no matter what OS you're using.
I think the point was that NTFS has to actually touch the files when they inherit permissions, whereas its better for admin if inheritance works without the files needing to be touched
The inheritable ACLs have to propagate (they can actually get out of sync). This is a design choice; either you check the inherited permissions at file opening or while changing the permissions or creating the file.
Chances are you will open the file more often than you will change ACLs so they chose the latter which makes sense.
This article is about the problems it causes (note that in Vista they changed the design so when moving a subtree the system automatically propagates permissions, removing a major cause of desyncs)
While you may be correct, those are basic functions that do not compare to what NT has. On Linux, you have to mount the FS with ACL support (I don't know if this is the default now) and manage them in parallel to the file system permissions, complicating the security model (without even going into SELinux and SUID 0 stuff). Due to legacy reasons, Linux's security model has evolved, while NT has had the luxury of a do-over during its design phase.
And those Windows ACLs form the foundation for higher level Windows security features like Active Directory, which itself is used as a foundation for many other aspects of Windows, so those ACLs are well and truly baked into the OS.
There's also no cross-platform filesystem with strong checksums (128-bit or 256-bit) for user data, and many popular user space databases (SQLite, PostgreSQL) also lack strong checksums for user data when last I checked.
This isn't really what you're looking for, but SMB is supported on all major desktop platforms. It's also supported on all major mobile platforms through third-party apps.
Instead of moving storage devices around, you might consider setting up a NAS and transferring files over the network. It doesn't work for every use-case, but it might be a viable alternative to many use-cases.
Sadly, exFat doesn't work reliably on Windows as I've had random software fail when data is stored on a drive formatted with exFat.
Mostly that's the software's fault, mistakenly assuming anything "not NTFS" is FAT32 and insisting I need to "upgrade" my drives, even though I'm only using it as project storage.
I honestly don't know why user mode software can tell what format the volume is in, and wouldn't just expect the OS to handle it or provide various feature flags like VOLUME_SUPPORT_LARGE_FILES or so.
'Random software' should not know anything about which file system your drive has.
If it does (..say.. some kind of whole disk backup utility), and you are using an unexpected file system that is not really a problem in exFat.
FAT/exFAT have good support across the three OS's, but they are very far from being "modern" filesystems. One of the most fundamental cons for me is the lack of journaling on these filesystems; it's very easy to corrupt a drive formatted as exFAT, especially if it's a portable device (which is probably one of the most important uses of a cross-platform filesystem)
This seems like a good start, and it could help provide more choice in cross-platform data storage and data exchange. Recently I looked once again, as I usually do once every few years, at options for exchanging data through external drives between Windows, macOS and Linux (I prefer USB drives, which are faster than speeds I can attain over the network). Shockingly, it seemed to me like NTFS was the easier filesystem to go with (Linux has good support for it, and macOS needs a third party driver for write support)!
Back to this project, I feel there is a strong need to have a set of GUI tools (beyond Windows Shell Extensions) to take advantage of the btrfs filesystem features (like creating snapshots, sending snapshots to backup storage, etc.). I use btrfs on Linux, and the lack of good, up-to-date GUI tools to use its feature set has been a source of frustration (yes, I can use the command line, but then that would restrict the usage only to me, leaving out the other not-so-tech-savvy people around).
> options for exchanging data through external drives between Windows, macOS and Linux
How is the UDF support on macOS? I ask since I relatively recently chose UDF as the Windows/Linux common HDD file system format, but I did not consider macOS.
The trick for cross platform UDF is formatting the whole stick as UDF, without partitioning (no MBR, GPT, or APM). In that case, it works, I tested this just last week on Windows 10, Fedora 26, macOS 10.12.
It's totally sane. It's "like" FAT32 except you don't have the 2G filesize limitation. NTFS might also be sane, but out of the box macOS doesn't have write support.
AFAIK it is fully supported, I also use often UDF, though for whatever reasons there are not so many users around, after all it is a formally documented and "standard" filesystem ISO/IEC 13346 and ECMA-167:
Right, macOS has had NTFS read support for quite a few years. I recently heard that the native driver can be enabled to provide write support as well. I just googled it and it requires editing /etc/fstab on a per-drive basis and has some downsides.
There are a few different external drives, for example the ones from Seagate and Toshiba, that come with NTFS drivers for Mac or allow the customer to download them for free. All external drives are also usually factory formatted as NTFS, in my experience.
ExFat it's great for USB flash drives and a easy way to get around this. But I had a few bad experiences with the lack of journaling working with a HDD.
Maybe not a deal breaker for a lot, but for crucial data, my advice will be build a cheap NAS with Linux inside, and pass all data between OSs over network
As a video editer the fuctionally of ExFat compared to Fat32 isn't even close to what I need them for. Fat32 can't store files larger then 4GB which is basically 99% percent of 4K videos that I deal with.
I would have preferred either a minimal update extending FAT32 to FAT64 (sort of like the extension from FAT12 to FAT32), or a better filesystem with journaling/etc.
Nice work. I've starred this simply because examples of Windows filesystem driver source are extremely rare. As are people familiar with both Windows and Linux development, which have very differnt styles and conventions.
This should have been done by Microsoft long ago, even before their little "Microsoft <3 Linux" gimmick with bash.
Still, a step in the right direction, at least on my book. My shared drives are all exFAT and that seems to work fine out of the box for Linux, Win and macOS.
"What's interesting to me is that there doesn't seem to be a modern filesystem that works across all major platforms."
What's interesting to me is that there is no modern filesystem that has a useful ACL mechanism. Say you have a tree of say 100M files and subdirs: now give rights at various points - it takes ages.
Your complaint can be worked around by remounting via an intermediary system and VMs are cheap. Mine is not really a complaint - per se - but a challenge: Why on earth can NSS (off of the 90s) do rich, recursive perms based on a "trustee assignment" on the fly but NTFS and Unix's finest not?
I'm using BTRFS on my SSD and while it has some neat features the need to rebalance periodically or you can "run out of space" while using less than half the SSD drives me crazy.
Kernel 4.8 and newer have a new ticketed enospc infrastructure that should avoid this, there's also earlier changes where empty block groups are deallocated automatically. If you're already using 4.8+ then try 4.12.6 or newer, which includes commit 4a309747.
Due to past long standing enospc challenges, more experienced users are in the (bad) habit of micro-managing Btrfs manually with filtered balance, e.g. -dusage=15 -musage=15. Really we kinda need to stop doing that to find and fix the remaining edge cases; or worst case upstream should deploy a systemd timer / cron job to do these partial balances maybe once a week.
Anyway I don't balance at all on my drives and haven't run into enospc in quite a while. So chances are you're hitting an edge case, and there's a bug that needs to be tracked down if you're already using 4.12.6+.
When I get home I'll have to check. I'm using it via UnRAID so I don't have as much control over the version I run but they are pretty good about releasing updates, I'm just bad about applying them and restarting because taking down Plex is a sin punishable by death lol
Oh the humanity. As someone switching away from BtrFS everywhere, everytime I've tried it over the years, I can just imagine what a Windows port "feels" like.
Why not reimplement it and prove the filesystem can be reimplemented sanely, and furthermore now has multiple implementations to test the specification against?
I'd wondered this, too. My first (wrong) assumption was that the author was aiming for a different license with the Windows version, but it's GPL.
If I had a guess, aside from "because I wanted to see if I could", it might be because of inherent differences in the way the OSes behave with regard to filesystems[0] would make a re-implementation from spec work better (faster, more reliably or whatever), though the author goes quite a ways to point out that he's used none of the original source, as if to state it's a clean-room implementation and I'd speculate (wildly) that though there are likely more than a few differences in Linux/Windows' APIs, there is almost certainly a lot about how btrfs works that isn't different when implemented on both platforms. These APIs would affect how the code is designed, and attempting to port by converting API calls that are Linux specific and plugging in similar Windows API calls could lead to a less-ideal implementation than if one read the spec and designed it targeting the operating system's API directly[1].
And then there's my original, wrong, assumption: if this individual is the only author, and it appears they might be, it does give him/her the ability to dual-license it later; i.e. offer a commercial license which doesn't have GPL-related requirements or switch it out to a less restrictive Open Source license if the author so chooses.
[0] I'm not an expert or even a n00b in this area. I, almost completely, know nothing about filesystem API differences between Linux and Windows since I don't know either the kernel interfaces for Linux or the Windows APIs related to the filesystem at any level having never written anything targeting that technology, directly.
[1] A former project that I built a long time ago comes to mind where I tasked with porting a tool to change what it used for storing records. The technology I started with had no concept of saving array records to disk, requiring a separate write for each record. Non-ideal, but not terrible because the technology was optimised at doing many small writes. The new target could accept an array of records and write them all in one call. I did a "compatible" re-implementation, replacing calls with their equivalent in the new record store and the performance made the product unusable. It wasn't until I redid all of the record I/O with the target platform in mind that things started working properly.
Probably never. We don't even have ext3 or ext4 support, only some bare ext2. And then there is the dozen or so other filesystems that would be handy to have. Microsoft doesn't care, they also don't have a business case for it, and they rather reinvent the wheel instead, using their own fs.
The FOSS community doesn't really care that much either, mostly because Linux can deal with NTFS, and the other way around happens far less, so no real push has been made for it.
Anyone know if there are any implementations for OSX/macOS? I tried OpenZFS and that worked great (tested on an SD card with LZ4 compression) but I didn't like the memory pressure it was putting on my system, even after tweaking. I really wish APFS supported transparent compression.
Looks interesting. If this is possible, I wonder why a driver for a much more common filesystem like ext hasn't picked of (e2fs driver does not count, that is ext2 only).
Ya I am using this and works with ext3/4 as well, but as you mentioned, there are some unsupported features. Unfortunately that means that it messes with some metadata or something and I have to run e2fsck when I reboot into linux. You can read about it here https://askubuntu.com/questions/849872/how-can-i-prevent-win...
I suspect someone is already playing the idea of implementing support for it, but if NTFS is any indication, it'll take a long time before anything stable exists.
There's also less motivation for implementing this filesystem in Linux at this point. It's available only on Server and Windows 10 Workstation (at least for creating -- I believe Win10 is able to read/work with ReFS in any version). It's not feature-complete yet[0], missing some important ones like deduplication. It's quite new, so there isn't a lot of it in the wild, reducing the need to make a compatible implementation for interoperability (probably the #1 reason for making a compatible version; #2 being to have a cool new filesystem with features that don't exist in currently available offerings). And being proprietary, it will almost certainly be a very difficult thing to write -- much like NTFS is/was.
[0] Not a show stopper - NTFS evolved over time, as all filesystems seem to.
FUSE is a Unix thing. I believe there is a port/similar thing for Windows, but I guess it would suffer the same kinds of limitations; namely performance, because everything is translated through userspace. That said, isn't it true that Windows drivers are userspace-based, anyway?
Keybase.io and sshfs use it, currently. Personally, I love it. I'm sure you're right about performance limitations, but there are very good use cases for it, like Keybase Filesystem and sshfs, where any latency introduced by the driver subsystem is less likely to be felt due to the latency of working with files over the network.
Interestingly, a set of the insider previews of Windows broke Dokany so badly that launching the driver caused everything to hang (hard -- all but the mouse stopped responding to anything, even CTRL+ALT+DELETE). It's tricky stuff, apparently.
All file system drivers must be kernel-mode on Windows. While Windows does have usermode drivers (UMDF), it's significantly gimped. Mostly just simple USB drivers or WDDM display drivers.
There have been a few projects to try to bring FUSE-like functionality to Windows like Dokan but I believe these are still too immature.
Ugh RHEL stopping commercial btrfs support in their long term support kernels [1] does not equate to btrfs "being phased out in linux distros". It's just Red Hat, and Red Hat was never a major btrfs promoter. It's also just commercial support, all Red Hat, Canonical and SUSE kernels will continue to be able to use it.
I'm not a btrfs fan myself (quite the opposite) but the gross way in which this minor Red Hat move is being exaggerated as the end of btrfs makes me think something's up. People are willing to spread the FUD a little too easily. Fact is that btrfs is still one of the top two most advanced filesystems in the world, part of the kernel, and SUSE for one is all in on it.
[1] They have legitimate reasons: it's a big chunk of code to maintain backports for and not at all popular in RHEL deployments.
I got bitten quite hard by some edge cases in the combination of btrfs, LUKS and snapper in desktop usage. It was both btrfs and the tooling around it as well as my ignorance. It's not a very interesting story.
Just to clarify, redhat never offered full support for btrfs, it was only a technology preview that they did not continue. So it was never "supported" in their commercial support agreement and not intended for production usage.
Ubuntu ships ZFS with their kernels. While this isn't an explicit thing, it strongly implies that Canonical doesn't have full confidence in btrfs.
As others have stated, Red Hat explicitly pulled engineering resources off btrfs.
ZFS just blows btrfs out of the water, there is really no comparison. As painful as it is to say, after all these years, btrfs still really feels like a rough draft of a modern filesystem.
That's no insult to the people who've done amazing work on btrfs over the years, it's just calling a spade a spade. Something was just missing in its development; maybe it was vision, cohesion, whatever it was at an organizational level, something stopped btrfs from really coming together as a first-class enterprise-ready FS. We should recognize that and let it go, as Canonical and Red Hat have gradually been doing.
If the choice is between memory contention and all of the issues that come with btrfs, I think memory contention is the better option.
That said, if the only issue is that ZFS's memory profile is too heavy for personal systems, that seems like something that justifies some tweaks to ZFS, possibly a "home use" operational mode, rather than a completely new FS, am I right?
I'm using ZFS without incident, but my workstation has 64G, so not really a good example...
Not to belittle the effort of the authors of this project, but when it's so easy to spin up a VM and feed the device through to it, it almost feels like we're past the point of needing native drivers for foreign filesystems. btrfs will surely work much better on a virtualized Linux kernel than through a buggy reimplementation of such a complex FS in Windows' driver platform.
I realize that designing a filesystem and writing drivers for it are very difficult tasks, but surely it would be extremely beneficial to have at least 1 open source filesystem that has good support across all platforms?