FUSE-T is a kext-less implementation of FUSE for macOS that uses NFS v4 local server instead of a kernel extension.
The main motivation for this project is to replace macfuse that implements its own kext to make fuse work. With each version of macOS it’s getting harder and harder to load kernel extensions. Apple strongly discourages it and, for this reason, software distributions that include macfuse are very difficult to install.
With Apple locking down macOS more and more, developers have to resort to ingenious solutions to maintain the same level of functionality as before. This is an example of that.
“With Apple locking down macOS more and more, developers have to resort to ingenious solutions to maintain the same level of functionality as before. This is an example of that.”
Not the same functionality but actually faster, better support for file-locks and better stability.
In this case it is clearly the better solution: this should not be in the kernel-space.
That’s the point. It doesn’t matter where it *should* live. The choice being largely taken away is what is egregious here. Replace this with a project that *does* need to be a kext and then what?
That said if this is what Mac users want, then have at it. No skin off the rest of our noses I guess.
It is the case with SCTP support:
https://github.com/sctplab/SCTP_NKE_HighSierra
No support for newer MacOS versions, whereas BSD/Linux have support by default. SCTP would be really useful as it offers a bunch of advantages over TCP/UDP but lack of support stifles its use.
bert64,
You know I’ve often wanted to use it as an upgrade over TCP but the lack of support for IP protocols beyond TCP, UDP, ICMP in operating systems and network infrastructure has been a huge problem that impedes adoption.
For better or worse, unless you run your own controlled WAN/LAN, other IP payloads are basically a no-go for internet applications targeting the masses š It’s too bad because SCTP would save having to roll our own TCP/IP or UDP/IP solutions in every application.
cybergorf,
Take a step back and think about what FUSE does in the first place. The entire goal is to create a userspace API for file systems. All FUSE file systems will be implemented in userspace using this API. So far so good. But now consider how FUSE itself needs to be implemented to hook up file systems into the OS. Ideally there would be a direct path from the FUSE API to the kernel, maybe even one implemented by apple themselves. However barring an official apple implementation of FUSE, the next best thing would be a 3rd party kernel implementation as follows:
KERNEL->FUSE KERNEL DRIVER->USER SPACE FILE SYSTEM
Moving the FUSE driver into userspace is a hack at best and it looks like this:
KERNEL->NFS DRIVER->TCP SOCKET->FUSE NFS SERVER EMULATION->USER SPACE FILE SYSTEM
This necessitates the generation, buffering, and parsing of TCP packets. This creates a significant overhead over read & write syscalls that typically would have been extremely efficient with a kernel driver that can read/write process memory directly.
Requiring FUSE to be underpinned by NFS further limits what our FUSE file systems can do. Say we want to implement memory mapping or some other feature that doesn’t map to NFS, well too bad because now everything has to be hacked in terms of NFS packets.
While this link is not related to this project or macos, it does highlight another problem introduced by having FUSE atop NFS model…
https://openafs-info.openafs.narkive.com/Dg6khf4t/openafs-microsoft-security-hot-fix-ms11-043-breaks-openafs-client
FUSE becomes dependent on an unrelated network file system and its changes. Consider if there are changes to NFS implementation or policy (say authentication/security/crypto/etc) these can potentially impact FUSE file systems that have absolutely nothing whatsoever to do with NFS.
The point being this is not an ideal way to implement FUSE. It’s a hack that exists to mitigate restrictions that have made it hard to install & use a proper FUSE kernel driver.
“Take a step back and think about what FUSE does in the first place. The entire goal is to create a userspace API for file systems. All FUSE file systems will be implemented in userspace using this API. So far so good. But now consider how FUSE itself needs to be implemented to hook up file systems into the OS. Ideally there would be a direct path from the FUSE API to the kernel, maybe even one implemented by apple themselves. ”
How can I quote here the way you did? Unable to find this option….
Answer:
Would that be the ideal solution? That was how it worked before – not done by apple but nevertheless a s a part of the kernel.
It was slower. Less secure and less stable.
So the new way. while seemingly more complicated, works better.
“The point being this is not an ideal way to implement FUSE.”
So it is more than ideal now?
I think there are too many variables to draw the conclusion that a kernel module is slower. There’s plenty of evidence to the contrary.
Without knowing the details of the kext implementation there could be heinous flaws that contribute to the slowness.
cybergorf,
WordPress uses HTML tags as follows:
<blockquote>quote</blockquote>
I keep telling osnews to put this in the site FAQ.
Well, the ideal solution really is a kernel driver assuming there weren’t other barriers at play. A kernel driver can clearly can do everything the NFS driver and more. And it should be more efficient too. However there may be obstacles in reaching the ideal solution, which seems to be the motivation for this project. Going through NFS is in no way ideal, but it may be the best option in light of apple increasing the obstacles for community supported kernel drivers.
Interestingly I faced the exact same conundrums with windows file system drivers and considered the same kind of hacks there. But I was fed up and it pushed me towards open platforms.
I was pretty surprised when they mentioned it is faster, but sounds good. Too bad Apple doesn’t provide an explicit API for alternative filesystem support, considering they are apparently discouraging kexts now.
Moochman,
I’m curious about that myself, but unfortunately there was no benchmarking data or indication of how benchmarking was done. Is anyone here willing and able to benchmark it?
They reference sshfs, and I wonder if that’s how they tested it? If so I would think that might be the bigger bottleneck rather than FUSE itself. To test FUSE’s own overhead it might be best to mount a loopback file system with minimal overhead and reading/writing many small files (as opposed to just one big file). This would place more stress on the FUSE implementation itself rather than remote network file systems. Does the NFS implementation on macos do client side caching? If so it could certainly skew results too.
That would be best IMHO. I’ve long wanted microsoft to support FUSE on windows too. And android too!! It just seems like 3rd party file systems are not a priority for any of these companies. It would be extremely useful to be able to mount all my network file systems from all my devices. I’ve been wanting to do this for years but support for open file systems is lacking. Native support for FUSE everywhere would be a godsend!
They do, but apparently it is funnier to bash Apple instead.
https://developer.apple.com/documentation/driverkit
moondevil,
Userspace drivers are common for USB periferals, but do they support userspace file systems? I didn’t see information about that in your link, but if they do then I would think it should be used instead of NFS.
IOUserBlockStorageDevice to the rescue,
https://developer.apple.com/documentation/blockstoragedevicedriverkit/iouserblockstoragedevice
moondevil,
Ah. I see that but that API is extremely limited. The IOUserBlockStorageDevice API appears to be designed for basic block devices like a thumb drive that read/write sectors and that’s all.
Consider that FUSE is not a block device but a file system. I think the reason why this project was designed to implement FUSE as an NFS server is because apple doesn’t have an appropriate API. Ideally apple would just implement FUSE or at least an equivalent for it that can be wrapped into the FUSE API. They don’t even have to write it themselves, it already exists and there’s nothing stopping them from buying and supporting the existing implementation as their own. It would solve the FUSE problem on mac.
More generally though I still dislike closed vendors deciding that it’s ok for us not have features that we want/need. If users want to run their own kernel drivers, then so be it, we should be allowed to. Many don’t like Linux and that’s ok with me, but at least there nobody is telling you what you can and cannot do – I value this freedom a lot. You get tons of flexibility and tools at your disposal and don’t need permission to mod your own system. I feel this leads to more innovation.
moondevil,
This is a tangent, but I noticed that IOUserBlockStorageDevice API is quite basic. For example it doesn’t look like the mac’s userspace DriverKit API supports a “trim” operation, which is used by file systems to tell solid state disks to return sectors to the unused pool. Solid state disks can use this fact to improve wear leveling algorithms and increase write performance. Also there is no SMART drive status monitoring either.
So it made me curious whether any manufacturers are actually using DriverKit block devices given the limitations. After some searching, it looks like macos has a tumultuous history with TRIM being introduced quite late and only being enabled for apple drives. There are lots of postings asking how to enable TRIM on 3rd party devices, but some saying just don’t do it or do it on another machine. This is all fascinating to me since I’ve mostly taken TRIM for granted.
https://appleinsider.com/articles/11/06/28/apple_brings_trim_support_to_all_ssd_based_macs_in_mac_os_x_10_6_8
https://discussions.apple.com/thread/252368448
https://forums.macrumors.com/threads/how-to-enable-trim-high-sierra.2131582/
You’re gonna have to do some mental gymnastics to equate that to ‘alternate filesystem support’.
Wow, this is so similar to the open source file systems that get hacked into windows by way of emulating an SMB server for windows to connect to (ie andrewfs/openafs). Everyone can agree this approach sucks, but sometimes it needs to be done as a last resort on platforms that are hostile to owner control.
I was working on my own installable file system for windows xp until microsoft started blocking unsigned DIY kernel drivers including my own. There were some hacky workarounds and tools to override the restrictions, but microsoft would break these tools with updates.
https://www.raymond.cc/blog/loading-unsigned-drivers-in-windows-7-and-vista-64-bit-x64/2/
You had to buy corporate code signing certificates to not get blocked. At that time this costed several hundred dollars per year and Individuals weren’t allowed even if they were willing to pay. I was livid and felt windows had become too hostile for DIY kernel development. I think this is largely why innovation on windows file systems stopped. They were turning away the very people who were putting in the work to improve windows. Most of us moved to linux. It would be many years later that microsoft begins to recognize the importance of FOSS and tries to attract linux developers back into their fold, but what a huge strategic mistake it was to make windows less attractive for power users and developers in the first place.
I’m not sure how much any of this applies to macos & apple. FUSE obviously offers a ton of flexibility and innovative potential. So if developers are having to rely on hacks to make it work on macos then I would think that’s a problem. But from apple’s perspective they might simply not care about 3rd party features & development. Could it be that apple just want macos to be more IOS-like rather than be a platform catering to developer needs?
wouldn’t it be even smarter to use https://developer.apple.com/documentation/fileprovider for most implementations? Maybe I am too ignorant, but most systems will map some filename to some background storage, faking a cloud file-storage behind the files seems the same stunt as using NFS as a shim, but in this case with native macOS support. If I am not mistaken the newest Google drive client uses this fileprovider thingy already.
I currently only need FUSE for gocryptfs, it’d be a good match for this fileprovider API I think (for doing normal file open/rename/write operations, running a DB ontop of it maybe not).
mike-kfed,
I think that’s an excellent suggestion/observation and I wonder how well it could work. It’s seems so close and yet it looks like there’s a very big difference with the API. Whereas FUSE (and NFS) forward individual read/write/lock requests on open files (essentially forwarding all userspace requests to the FS provider), this API acts on the entire file and relies on the provider to transfer it atomically using the fetchContents and modifyItem methods. FUSE doesn’t normally work this way. A naive conversion of reading the entire file and overwriting the entire file would be possible, but that could have undesirable side effects and data loss in some cases.
I think there are a lot of cases where this could work ok too, but the granularity wouldn’t be the same. Applications/Databases that use fine grained concurrent access would be problematic. Or say you have an application that only needs to read part of a file, like a game with 15GB of resources in large files. Normally going through FUSE the application would only read the assets it needs on demand but the File Provider API would have to download the entire file. This would be especially silly to do if the both the downloaded copy and FUSE copy resided on a local drive. You’d incur 15GB of pure overhead using the File Provider API.
I *think* FUSE could be treated as a superset of the File Provider API. If you have a use case that already works through an existing File Provider link like google drive, then I don’t see a reason it wouldn’t work through the same API with a FUSE backend. The contrary wouldn’t necessarily be true though because apple’s File Provider API is only a subset of FUSE.